Matrix.org - Encryption

"Exclude insecure devices" is coming

2025-11-19T00:00:00+00:00

The Spec Core Team would like to remind everyone that, now that MSC4153</a> has been accepted, the Matrix spec recommends that “Encrypted to-device messages SHOULD NOT be sent to non-cross-signed devices”.

In short: if, as a user, you have client devices which haven’t been correctly cross-signed with your identity key, then you’re going to start finding yourself unable to read encrypted messages from other users on those devices.

If you missed Andy’s talk</a> on this at the Matrix Conference, we strongly recommend watching it as he explains the hows and whys of this change, but to summarise: this is an important improvement to the security of end-to-end encryption in Matrix.

As Andy also mentions in his talk, Element is planning to change the defaults in its clients to follow MSC4153’s recommendations to exclude non-cross-signed devices in April 2026. In preparation, the Element clients will very soon start to force users to verify their own devices so that those users are not shut out come April.

If you are a client developer, we encourage you to take a similar approach of encouraging users to verify their devices, so that they are not excluded from the conversation as the ecosystem moves towards MSC4153 compliance. And if you are a user, make sure your devices are verified!

Libolm Deprecation

2024-08-27T14:00:00+00:00

It’s been a few weeks since we announced the deprecation of libolm</a>. Since then, we’ve fielded some questions on the subject and thought it would be helpful to collect this context in a blog post.
First up, a recap. We first introduced the idea that libolm would make way for vodozemac</a> in 2022, following the Gematik</a> sponsored audit from Least Authority</a>.
Since then, various client implementations have migrated to vodozemac</a>. Notably, all versions of Element, Element X, Fractal, iamb and other matrix-rust-sdk</a> based clients and their forks already use vodozemac, and platforms using matrix-js-sdk can also use vodozemac instead of libolm.
In This Week in Matrix 2024-08-02</a> Matthew</a> formally announced the deprecation of libolm in favour of vodozemac. 

Heads up that we have officially marked the original C/C++ libolm implementation as deprecated, as warned back in May 2022</a> when we announced the Rust vodozemac implementation as the successor to libolm. The rationale for doing so now is that all of the SDKs maintained by the core team at github.com/matrix-org</a> now support vodozemac, and the majority of apps built on top of them have now successfully switched over to vodozemac. Meanwhile, we simply don't have bandwidth to maintain and support both vodozemac and libolm, so our maintenance will be focused on vodozemac going forwards. You can find the official deprecation notice here</a>. </blockquote>
Matthew then followed up in This Week in Matrix 2024-08-16</a> in light of the coordinated disclosure by security researcher Soatok of potential security weaknesses in libolm</a> underpinned by the primitives employed by the library.
Quoting selectively:

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</a> (or fork libolm to add better primitives). We should have done a better job of explicitly deprecating libolm sooner (and/or improving its primitives) – but all of our focus has been on ensuring that vodozemac is excellent, to the detriment of libolm. Apologies to those who are now finding themselves expediting libolm replacement. </blockquote>
So what does this mean if you are building an app that has a dependency on libolm?
We have been public from the outset that that libolm's primitives are functionally correct, but not resilient to timing attacks

Repository issue</a></li>
Project README</a></li>
An audit from NCC Group</a></li> </ul> </li>
We do not believe this to be a high-severity issue for Matrix because an attack would require sending very large volumes of messages with very accurate timings targeting the same key material – while in practice Matrix implementations have short-lived AES key material (due to ratcheting), very noisy timings (due to traffic topology being client ↔ server ↔ server ↔ client, with persistence steps at each hop), as well as traffic rate-limiting. As a result, we do not believe that an attack over the network is feasible. It is possible that a local attack might work – but if the attacker has local access to your device, we consider you to already be compromised.</li>
Even though it is a theoretical rather than practical weakness, we still wanted to fix it. We chose to do so with the shift to vodozemac, which provides both first-class, audited cryptographic primitives provided by Rust, while also avoiding the possibility of an entire class of weaknesses, such as the buffer overflows</a> previously found and mitigated in libolm.</li> </ul>
We've deprecated libolm simply because we do not have the bandwidth to replace its primitives as well as maintain and evolve</a> vodozemac.
Given the above, in the context of Matrix, libolm is currently safe to use in a practical sense (with the above caveats). However, we strongly encourage all app developers to chart a path away from libolm in favour of vodozemac.
Additionally, we have registered three CVEs to track recently highlighted vulnerabilities.

CVE-2024-45191 - AES implementation is vulnerable to cache-timing attacks</a></li>
CVE-2024-45192 - Base64 implementation used for decoding sensitive data has a timing side-channel</a></li>
CVE-2024-45193 - Ed25519 signatures are malleable</a></li> </ul>
Note: The CVEs have since been edited post-submission to conflate libolm with the Olm protocol itself. A genuine protocol vulnerability would be much more serious so we are working with MITRE to clarify.
The good news is that if you are building on matrix-rust-sdk or matrix-js-sdk they are already vodozemac backed. However, libolm is still a dependency of both libraries, and it is worth explaining why.
matrix-rust-sdk
libolm is used only in testing and is not an operational dependency (it is used to check that PkEncryption</code> in matrix-sdk-crypto is compatible with libolm's). We have updated</a> its dependency specification to make this clearer. We do not intend to remove this dependency in the short term.</li> </ul> matrix-js-sdk libolm is referenced here</a>, as a hangover from recent work to migrate from libolm to vodozemac. This file will be removed</a>.</li> </ul> Additionally, the legacy mobile SDKs, matrix-android-sdk2</a> and matrix-ios-sdk</a>, also have dependencies on libolm. It is used there for the following: To encrypt the bodies of the requests for the Element maintained content scanner</a> project. These references are unused in any publicly available application and will be removed.</li> To support migration of users from legacy crypto to Rust crypto. Given the adoption of Rust crypto in March 2023 for iOS and July 2023 for Android we will remove this support in the near future, once we have confirmed that the vast majority of users have migrated.</li> For unused legacy QR code log-in functionality in matrix-android-sdk2. This will be removed shortly.</li> </ul> To conclude, we see the deprecation as a natural step in a multi-year process. In retrospect, we could've been a lot more explicit in explaining the context of the libolm deprecation and offer our apologies. Hopefully, this post makes things clearer. However, by formally deprecating libolm we make the direction of travel extremely clear and we recommend all projects adopt a vodozemac-backed solution promptly or alternatively fork libolm and upgrade the primitives. If you have any questions or concerns, please reach out to security@matrix.org</a>.
A giant leap forwards for encryption with MLS 2023-07-18T14:00:00+00:00 Hi all, Given our commitment to open standards and interoperability, we’re delighted to see MLS be ratified by the IETF as RFC9420</a>. MLS is a new encryption standard defined by the IETF, the standards body that maintains much of what makes the internet work. In the same way that Transport Layer Security (TLS, another IETF standard) defines the way to provide encryption between users and servers, or between two different servers, MLS provides a standard way for users of a messaging service to communicate securely without servers being able to eavesdrop on their conversations. Since Matrix is a proponent of open standards and secure communication, MLS is a great fit for us, and we were pleased to participate in the standardization process along with many other organizations. By being produced in the open, MLS was able to benefit from the experience and knowledge of a huge cross-industry group of individuals. Since the beta launch of end-to-end encryption in Matrix in 2016, we’ve been working on improving the end-to-end encryption experience for users while ensuring that conversations remain secure. End-to-end encryption is an important part in ensuring that people can communicate safely and securely with each other, whether it be about healthcare, financial, government, business, or personal information. MLS provides more opportunities for improving the security of conversations in Matrix, and offers those building on Matrix more flexibility. MLS is particularly useful for conversations with large numbers of participating users, thanks to algorithmic improvements over the Double Ratchet most systems use today. It also introduces new security guarantees, such as the ability for group members to cryptographically verify the recipients of a message. We have been working on integrating MLS into Matrix since 2020 to take advantage of its benefits; the biggest task has been developing approaches to enable MLS to operate in decentralised environments such as Matrix or the IETF’s MIMI working group</a> for interoperable instant messaging. With other interested parties, we’re continuing to develop best practices for MLS that will work without modification in a decentralized environment which should be available for testing later this year. We should also highlight that much of the work to create and use MLS in a decentralized environment comes from a commercial arrangement between BWI and Element to create ‘Matrix over MLS’ for use by the German Armed Forces, to further secure its own solution BwMessenger and to make it interoperable with other messaging products. BWI’s funding of Element’s open source development of MLS has massively accelerated support for Matrix over MLS. It’s why commercial arrangements with vendors building on Matrix are so important for Element, who employs the majority of the Matrix core team. Matrix vendors can also now directly financially support The Matrix.org Foundation as paying members too. You can keep track of our progress at https://arewemlsyet.com</a> -- Matthew, Hubert & the Matrix cryptography team