Post Al1FBlAph2tMVuVHTE by cryptgoat@digitalcourage.social
 (DIR) More posts by cryptgoat@digitalcourage.social
 (DIR) Post #Al1FBlAph2tMVuVHTE by cryptgoat@digitalcourage.social
       2024-08-15T11:00:26Z
       
       0 likes, 0 repeats
       
       FYI: A ton of third party #Matrix clients use the deprecated #libolm library for end-to-end encryption which suffers from multiple vulnerabilities:https://soatok.blog/2024/08/14/security-issues-in-matrixs-olm-library/libolm has been deprecated for a while now.There is a "new" #Rust based crypto library called #vodezemac that has been used by the official #Element clients for about 2 years.Personal recommendation: Only use Element / #ElementX for now, #FluffyChat and #Nheko are working on their clients: https://github.com/krille-chan/fluffychat/issues/1258https://github.com/Nheko-Reborn/nheko/issues/1786#issue-2441024627#Security #Messenger #Olm #FOSS #Privacy
       
 (DIR) Post #Al1FBlySiWagzpiupM by deepbluev7@nheko.io
       2024-08-15T20:14:51.218Z
       
       1 likes, 1 repeats
       
       @cryptgoat@digitalcourage.social libolm was deprecated less than a month ago. Nheko didn't even have a release since then. The security vulnerabilities found are also basically impossible to abuse remotely to my understanding and were in at least some parts documented since the start of libolm's development.Calling libolm deprecated "for a while now" is just plain wrong. While it was implicitly communicated, that development would focus on vodozemac, until a few weeks ago there was no statement, that libolm would not receive security fixes. Similarly there were also a few libolm releases after vodozemac development started, some of them I even contributed to. Additionally vodozemac is not a complete replacement for libolm, you kinda need to pull in the crypto-crate for that or reimplement some functionality on your own. The assumption in a lot of projects was, that they would switch, once vodozemac would be a complete libolm replacement. Sadly there is no interest by the maintainers to make it that.Libolm has been audited twice, in neither case were the current "security issues" raised as a critical concern. They are not great, but they don't really impact the threat model of a normal Matrix client, as far as I am aware. Meanwhile vodozemac had a minor security vulnerability, where it wouldn't zero buffers properly on discard, because some of the rust dependencies changed their default flags.Basically, the security issues are not a real threat. The blog posts makes it sound like a much bigger issue than it is. There also has not been sufficient time to judge, if libolm actually stays unmaintained or now that it is officially deprecated, maybe someone else picks it up and ports it to use a proper crypto lib underneath (like openssl). There also hasn't been enough time to actually write proper language bindings for vodozemac to make it usable for other clients than Element clients. Basically people are widely overstating the impact of this because of the language in the original post. The real reason to use Element over Nheko is because Element has a proper security team, while Nheko is developed by people in their free time. However that doesn't mean that Nheko didn't avoid some of the security issues Element fell into, but it might have its own security issues, since nobody ever audited it.