I don’t consider myself exceptional in any regard, but I stumbled upon a few cryptography vulnerabilities in Matrix’s Olm library with so little effort that it was nearly accidental. It…
I don’t consider myself exceptional in any regard, but I stumbled upon a few cryptography vulnerabilities in Matrix’s Olm library with so little effort that it was nearly accidental.
It should not be this easy to find these kind of issues in any product people purportedly rely on for private messaging, which many people evangelize incorrectly as a Signal alternative.
FWIW, current versions of the reference client (Element) don't use the Olm library (libolm), which is now deprecated.
From the README:
libolm was Matrix's first implementation of the Double Ratchet algorithm, dating
back to 2015. It is not written in memory-safe langauges (C and C++11),
resulting in several CVEs over the years (e.g. CVE-2021-34813 and
CVE-2021-44538). It also depends on simplistic cryptography primitive
implementations which are intended for pragmatic and education purposes rather
than security - e.g. Brad Conte's crypto-algorithms.
We’re not aware of any way to actually exploit these weaknesses over the network, but we continue to strongly recommend developers to migrate to vodozemac (or fork libolm to add better primitives).
Nevertheless, if you're using a third-party Matrix client that depends on libolm, you might want to contact its developers, or switch.