Skip to content
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

Open
gmacon opened this issue Aug 1, 2024 · 6 comments
Open

libolm is deprecated #262

gmacon opened this issue Aug 1, 2024 · 6 comments

Comments

@gmacon
Copy link

gmacon commented Aug 1, 2024

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?

@tulir
Copy link
Member

tulir commented Aug 1, 2024

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.

@gmacon
Copy link
Author

gmacon commented Aug 1, 2024

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.

@tulir
Copy link
Member

tulir commented Aug 14, 2024

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.

@gmacon
Copy link
Author

gmacon commented Aug 14, 2024

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.

@tulir
Copy link
Member

tulir commented Aug 15, 2024

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

@sumnerevans
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants