-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use better AES/SHA implementations #3
Comments
richvdh
changed the title
Use better crypto primitives
Use better AES/SHA implementations
Apr 3, 2017
libsodium is a pretty good implementation of various crypto primitives... I think it only does AES-GCM, not AES-CBC however :/ |
Update: the modern solution to this is just to use https://github.com/matrix-org/vodozemac, which uses better implementations. |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
At present, libolm uses Brad Conte's portable implementations [1] of SHA-256 and AES-256. These have the advantage of being plain C and therefore work out-of-the-box under emscripten; however they are not side-channel resistant.
I'm not aware of any portable implementations of AES which are resistant to side-channel attacks - indeed it is very difficult to create a constant-time implementation without access to machine-level detail. The correct fix to this is therefore to use different implementations in different environments - for example, we could link against openssl for a C library, and use webcrypto in the browser.
It's also likely that doing so would bring performance improvements.
The main difficulty is that it significantly changes data flows: for example, webcrypto provides an asynchronous interface, which means that the whole olm interface would need to be altered to be asynchronous, at least under emscripten.
The text was updated successfully, but these errors were encountered: