-
-
Notifications
You must be signed in to change notification settings - Fork 78
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
libolm is deprecated #262
Comments
There's no new vulnerability in libolm, it's just that the crypto primitive implementations aren't resistant to side-channel attacks. It's not a secret, it's mentioned in the deprecation notice and has technically always been documented in the libolm repo (https://gitlab.matrix.org/matrix-org/olm/-/blob/master/lib/crypto-algorithms/README.md) Honestly soatok's obnoxious behavior makes me want to ignore the whole problem, but that's obviously not a very constructive approach, so we'll switch away from libolm at some point. Not yet sure if the result will be finishing goolm or adding vodozemac support, but definitely one of the two. Beeper will probably get goolm audited after it's ready. |
That's very interesting, thanks for the information! I guess I was reading too much into the "watch this space" notice from soatoak; I was expecting a new memory-safety bug leading to RCE or something along those lines that's actually a serious problem. |
FTR the full blog post has now been published: https://soatok.blog/2024/08/14/security-issues-in-matrixs-olm-library/ My comment above still applies, but at least the blog post isn't pure fearmongering like the earlier toot. |
I read the blog post, and I think that the original message was probably written with a level of urgency appropriate for the counterfactual where the EdDSA nonce observation was actually an issue and not just misreading the code. |
Yeah it would've been appropriate for that, except the EdDSA thing was found to be incorrect on May 17th according to the timeline, while the toot was posted on July 31st |
I just merged a PR to allow goolm and libolm to exist side-by-side: #211. This means that we can test libolm and goolm against one another and make sure that goolm adheres to spec. |
The Matrix developers have deprecated libolm. I haven't seen an official statement about why, but, based on the timing, it seems that this is because there's a vulnerability of some sort with a coordinated disclosure deadline of August 14. The official replacement for libolm is vodozemac, but it's written in Rust and they don't appear to have any official C API that I could find.
I see you already have a pure-Go implementation of the Olm protocol, so my suggestion would be that you switch to that (and address the vulnerability, whatever it is, if it's a protocol vulnerability instead of an implementation flaw in libolm).
As a side point, and please let me know if there's a better place to ask this question: Has there been a cryptographic audit of goolm?
The text was updated successfully, but these errors were encountered: