Release

We’re releasing OpenMLS 0.9.0, our latest step toward a stable, standards-compliant implementation of Messaging Layer Security (MLS, RFC 9420). 📦 https://crates.io/crates/openmls Migrating storage between formats If you’ve been running OpenMLS in production, you’ve probably had to think about how group state is serialized on disk. 0.9.0 adds an opt-in migration-import feature that gives you a path to move existing group state to a storage provider using a different serde codec. For example, from bincode to CBOR. MlsGroup and PublicGroup both gain import entry points that re-read state with the old codec and fully rewrite it with the new one. We’ve also added a new book chapter walking through the eager and lazy per-group migration strategies. ...

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. ...

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: ...

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. ...