You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
richvdh
changed the title
Use better crypto primitives
Use better AES/SHA implementations
Apr 3, 2017
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: