A WIP Rust implementation of Messaging Layer Security based on draft 9+

Messaging Layer Security based on draft 9+


A WIP Rust implementation of Messaging Layer Security based on draft 9+.

Supported ciphersuites

  • MLS10_128_HPKEX25519_AES128GCM_SHA256_Ed25519 (MTI)
  • MLS10_128_DHKEMP256_AES128GCM_SHA256_P256
  • MLS10_128_HPKEX25519_CHACHA20POLY1305_SHA256_Ed25519

Supported platforms

OpenMLS is built and tested on the Github CI for the following rust targets.

  • x86_64-unknown-linux-gnu
  • i686-unknown-linux-gnu
  • x86_64-pc-windows-msvc
  • i686-pc-windows-msvc
  • x86_64-apple-darwin

Additionally, we're building and testing aarch64-unknown-linux-gnu on drone.io.

The Github CI also builds (but doesn't test) the following rust targets.

  • aarch64-apple-darwin
  • aarch64-unknown-linux-gnu
  • aarch64-linux-android
  • aarch64-apple-ios
  • aarch64-apple-ios-sim
  • wasm32-unknown-unknown

OpenMLS only supports 32 and 64 bit platforms.



OpenMLS does not implement its own cryptographic primitives. Instead, it relies on existing implementations of the cryptographic primitives used. There are two different cryptography backends implemented right now. But consumers can bring their own implementation. See traits for more details.


OpenMLS requires at least Rust 1.56.0.


  • run cargo build


  • run cargo test


  • run cargo bench


This repository is a cargo workspace with the OpenMLS library as the main component.

In order to use OpenMLS an implementation of the traits is required. This repository provides two default implementations

  • Rust Crypto
  • Evercrypt

It further holds the following crates that are used for testing.

Delivery Service

A basic delivery service can be found in delivery-service/ds. To interact with the delivery service the ds-lib provides the necessary types.

Command line Client

A basic command line client can be found in cli. Note that this is a PoC for testing and must not be used for anything else.


OpenMLS is licensed under the MIT license. The license can be found here.


OpenMLS welcomes contributions! Before contributing, please read the contributing guidelines carefully. You can start by looking at the open issues or join the discussion on GitHub discussions or Zulip.

Code of conduct

OpenMLS adheres to the Contributor Covenant Code of Coduct. Please read the Code of Conduct carefully.


Collection of the latest Issues



mls-spec change

Description of the changes This PR moves the signature key from Credential to LeafNode, to ensure that an MLS client always has a signature public key with which to verify messages, even if it does not support a member's credential type.

This is an alternative approach to https://github.com/mlswg/mls-protocol/pull/628, and IMO a bit cleaner. We no longer need the notion of a SignatureScheme, since BasicCredential doesn't stand alone. And since Credential only appears in LeafNode, common fields can be hoisted up into LeafNode. The Credential struct really only exists as a conceptual boundary, to make the exposition clearer; otherwise you could just shove the select into LeafNode.

Note that this does not obviate the need for https://github.com/mlswg/mls-protocol/pull/631. This PR only ensures that the signatures can be processed; that PR helps ensure that the signatures are meaningful.

Link to the exact changes https://github.com/mlswg/mls-protocol/pull/637




The key package calculation in KeyPackage::hash_ref is using the wrong label: here the label is hardcoded to "MLS 1.0 ref", while the spec mandates "MLS 1.0 KeyPackage Reference". Presumably this is a problem for proposals as well.




Currently we sometimes filter invalid proposals out and sometimes throw errors during validation. We should make this consistent. The simplest proposal would be to only do filtering with a first-come-first-serve approach.




The self_update function of the mls_group API takes an optional KeyPackage as input. When that happens, the function creates an update proposal from that KeyPackage and tries to commit it. However, committing update proposals with one's own KeyPackages is not allowed and the path must be used instead.

For the function to change this behaviour, the CreateCommitParams struct needs to allow the caller to pass in an explicit KeyPackage, which can then be used as basis for the path. Also, a test should be added that actually does this.



  • add_members(): Early add proposal validation would be nice (instead of the validation that happens anyway as part of the commit creation
  • remove_members(): Check the members are actually part of the group, early remove proposal validation
  • propose_add_member(): Do full validation right away (right now only required extensions are checked)
  • propose_remove_member(): Do full validation right away
  • Check if more needs to be done for self updates



This ticket tracks other tickets related to the validation of trees that the client receives.

  • create list of tree validation steps
  • #800
  • parent hash validation (documentation and testing)
  • node validation (only keypackages in leaves, only parent nodes in non-leaves)

Find the latest versions by id

v0.4.1 - Jun 07, 2022

This release addresses API issues for the crypto-subtle feature as well as External Commits.


  • #873: Signature sub-module of the ciphersuite module is now public.
  • #873: Signature keys can be imported and exported with the crypto-subtle feature.
  • #873: BasicCredentials can now be created from existing signature keys.


  • #890: Join group by External Commit API does not expect proposal store.

v0.4.0 - Feb 28, 2022

💡 This OpenMLS release catches up with most of the spec changes and offers a first usable public API. It is an implementation of draft 12+. See this blog post for more details on this release.

🦀 Crate: https://crates.io/crates/openmls 👩🏾‍💻  Rust docs: https://docs.rs/crate/openmls 📚 Manual: https://openmls.tech/book/

❗️ This release is not implementing a published RFC and is not interoperable with other MLS implementations. There will be breaking changes.

This release includes releases of the following dependencies

  • openmls_traits: v0.1
  • openmls_rust_crypto: v0.1
  • openmls_evercrypt: v0.1

Information - Updated Jun 13, 2022

Stars: 158
Forks: 21
Issues: 120

Repositories & Extras

Rust bindings for libinjection

Add libinjection to dependencies of Cargo

Rust bindings for libinjection

Rocket is an async web framework for Rust with a focus on usability, security,

Visiting localhost:8000/hello/John/58, for example, will trigger the hello

Rocket is an async web framework for Rust with a focus on usability, security,

Rust bindings for the C++ api of PyTorch

LIghtweight wrapper for pytorch eg libtorch in rust

Rust bindings for the C++ api of PyTorch

Know the exact crate versions used to build your Rust executable

Audit binaries for known bugs or security vulnerabilities in production, at scale, with zero bookkeeping

Know the exact crate versions used to build your Rust executable

macOS/iOS Security framework for Rust

MIT license (LICENSE-MIT or

macOS/iOS Security framework for Rust

Reference implementation of the Stacks blockchain in Rust

Reference implementation of the Proof of Transfer (PoX) mining that anchors to Bitcoin security

Reference implementation of the Stacks blockchain in Rust

osu! server written in Rust

Fully asynchronous, high concurrency, high performance, and high security

osu! server written in Rust

Nakamoto is a privacy-preserving Bitcoin light-client implementation in Rust,

with a focus on low resource utilization, modularity and security

Nakamoto is a privacy-preserving Bitcoin light-client implementation in Rust,

Rust Language Security

execrices: RUSTSEC-2021-0001

Rust Language Security


Many thanks to the authors of the openpgp-card Rust crate


Owlyshield open source security platform

An OSS security platform written in rust with security threat detection

Owlyshield open source security platform
Facebook Instagram Twitter GitHub Dribbble