Openmls

OpenMLS Development Update - September 2024 Welcome to the inaugural post in our new series, designed to keep you informed about the latest developments on OpenMLS. Each month, we’ll highlight significant changes, share key milestones, and provide insights into our ongoing work. At the beginning of September we released OpenMLS v0.6 | 📦. The month has been pretty quiet after the release while we started to complete the semantic validation checks in OpenMLS to ensure that OpenMLS is always safe to use. Read more about it in Jan’s blog post. ...

When implementing cryptographic protocols, probably the most important thing is to not forget validating all inputs. Failing to do so can lead to inadvertant leakage of private information, state corruption, impersonation attacks… all kinds of vulnerabilities. To give an example, you might remember the “goto fail” vulnerability, a bug in the TLS implementation used in iOS. Here, the verification function of signatures sent along with the ServerKeyExchange message, which ties the server identity to the transcript and ephemeral key material. Due to a hard-to-spot slipup, it returned success early and never really checked the signature, which would allow an attacker to man-in-the-middle the connection. While in this case they didn’t just forget to do the check, it does demonstrate why these checks are important. ...

Today, we are releasing version 0.6 of OpenMLS. In this post we’ll go over the most significant changes since our last release. New Storage Provider To make it easier to persist group state, the KeyStoreProvider was replaced with the more powerful StorageProvider trait for tracking the state of a group or a party. This includes keys, but also other group state like the ratchet tree and the group context. OpenMLS writes to the storage at the end of any successful operation. This means that if the provider is backed by some persistent memory, the entire long-lived state of OpenMLS is automatically persisted. ...

OpenMLS now offers security against harvest-now-decrypt-later (HNDL) quantum adversaries. In #1546 we merged support for the X-Wing KEM draft, which is an early draft for securely combining elliptic-curve-based Diffie-Hellman with ML-KEM. In particular, OpenMLS now supports the ciphersuite MLS_256_XWING_CHACHA20POLY1305_SHA256_Ed25519 with ciphersuite 0x004D. There is no IANA code-point for this ciphersuite yet, such that interoperability may not be guaranteed. We work with other implementers towards interoperability of this ciphersuite. The implementation uses Cryspen’s formally verified ML-KEM and x25519 implementations from libcrux. The implementations are not only formally verified for correctness, secret independence, and memory safety, but also amongst the fastest implementations. Users should not notice any significant performance differences when using this new ciphersuite. The threat of HNDL attackers requires applications to switch to post-quantum secure mechanisms now, just like Signal and iMessage did already. OpenMLS offers a simple way to achieve security against HNDL attackers and is ready to use. ...

Today, we are releasing OpenMLS v0.5. This release has been a while in the making and covers substantial changes since the last release. We are grateful for the support of the Sovereign Tech Fund towards this goal. These are some of the changes: The implementation caught up with the latest changes in the protocol specification. The last version was roughly based on draft 12. Since then, the protocol has iteratively evolved all the way through draft 20. The library now implements the wire format of messages and mechanisms specified in RFC 9420. Extensive interoperability testing has been done between OpenMLS, Cisco’s MLS++, and another closed-source MLS protocol implementation. The goal of this exercise was to validate the last set of changes in the specification and ascertain that all implementations implemented the specification correctly. The next phase Until recently, the specification was a moving target and so was the implementation. Now that the specification is no longer subject to changes, the implementation can finally mature in terms of correctness, ease-of-use, and efficiency. We would like OpenMLS to be as useful as possible to those who consider end-to-end encryption with MLS. We are ready to evolve the library in the following areas: ...

After a few months of silence, we are picking up work on OpenMLS again! 🎉 Phoenix R&D and Cryspen join forces to bring OpenMLS closer to v1.0. The MLS protocol draft is in the IETF working group’s last call and is thus on track to become an RFC soon. We want to make sure that OpenMLS is ready for wider adoption by the time the RFC is ready. To achieve this we start by catching up with all the changes to the protocol (up to the current draft-16), improving test coverage of the code, and working towards a more comprehensive test framework for interoperability. ...

Today, we are excited to announce the release of v0.4 of OpenMLS! 🎉 Some time has passed since we wrote about our roadmap to v0.4. In this post, we want to provide some insight into what has happened in the development of OpenMLS generally, but also relative to the goals we included in the roadmap. Our high-level goal with v0.4 was to reach a state where we have an API stable enough and an implementation robust enough such that people interested in OpenMLS can start exploring it in the context of their own projects. However, this is not v1.0 and we can neither promise that the API won’t change in the future, nor do we advise using OpenMLS in production or indeed in any security-sensitive context. With this disclaimer out of the way, let’s see what has happened in these past months. ...

It’s time for another update on OpenMLS because many things are happening behind the scenes. Today we are excited to announce a public roadmap for OpenMLS v0.4. This will not even be close to a v1.0 release because the spec is still not finished and it’s unclear how the library will be used. Nonetheless will v0.4 be a significant release with a mostly stable API and most functionality being implemented. Over the next five months we will fix the most pressing issues and make OpenMLS a usable MLS library for consumers to use. We are well aware that there is almost no experience with using MLS in a messaging product. (Cisco’s Webex is rolling out MLS for end-to-end encrypted video calls as part of their zero-trust initiative right now.) The goal is therefore to offer a mostly stable API and complete feature set for consumers to start using it. However, we expect a significant feedback cycle to improve the APIs to make OpenMLS better suited for applications. ...

In this blog post, I explore how MLS’ aspiration to be scalable manifests itself in OpenMLS. The charter in particular claims the following: Resource requirements have good scaling in the size of the group (preferably sub-linear) While performance can be theoretically analysed for MLS it is also interesting to see whether the performance goals hold up in a real implementation. This of course only looks at a single implementation. Nonetheless, I think that it gives a good impression on the actual performance of MLS implementations. Particularly because OpenMLS at this point is not optimised but rather implements the MLS spec as is. ...