openmls / openmls

Rust implementation of the Messaging Layer Security (MLS) protocol

OpenMLS

OpenMLS is a Rust implementation of the Messaging Layer Security (MLS) protocol, as specified in RFC 9420.

It is a software library that can serve as a building block in applications that require end-to-end encryption of messages. It has a safe and easy-to-use interface that hides the complexity of the underlying cryptographic operations.

Supported ciphersuites

• MLS_128_HPKEX25519_AES128GCM_SHA256_Ed25519 (MTI)
• MLS_128_DHKEMP256_AES128GCM_SHA256_P256
• MLS_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

Unsupported, but built on CI

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
• armv7-linux-androideabi
• x86_64-linux-android
• i686-linux-android

OpenMLS supports 32 bit platforms and above.

Cryptography Dependencies

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

Working on OpenMLS

For more details when working on OpenMLS itself please see the Developer.md.

Maintenance & Support

OpenMLS is maintained and developed by Phoenix R&D and Cryspen.

Acknowledgements

Zulip graciously provides the OpenMLS community with a "Zulip Cloud Standard" tier Zulip instance.

openmls's Issues

Fix tree math (#359)

mlswg/mls-protocol#359

Crypto provider trait

Pass in a crypto provider object instead of selecting them by feature.

• #486

Don't keep around old ratchet secrets

If I understand the code correctly, we keep around old ratchet_secrets in the past_secrets field of the SenderRatchet.

Instead, if we skip one ratchet step due to an out-of-order message, we should derive the corresponding ratchet_key and ratchet_nonce and keep those instead, deleting the old ratchet_secret. Otherwise, we don't achieve optimal FS.
https://github.com/raphaelrobert/maelstrom/blob/ac0ea4d01af7ebe616abf85cd7531a89a3ce4263/src/astree.rs#L139

Use the same tree for Handshake and Application secrets (#401)

mlswg/mls-protocol#401

update_direct_path: return error if public keys don't match

Update BasicCredential (#402)

mlswg/mls-protocol#350

[Meta] Persistence

We need to be able to persistent MLS groups and key material to disk and load it again.

also see #80

create_commit

I don't understand how to use create_commit. There are two different arguments for KeyPackageBundle that are unclear how to use and there's no way to create a Sender to pass in proposals.

https://github.com/raphaelrobert/maelstrom/blob/843120c6821d4e01304ba92127749889f7817ce3/src/group/mls_group/api.rs#L61-L69

Remove own_keypackages from create_commit

They shouldn't be necessary. Remove them from API, code, and spec.

Implement changes to sender data encryption (#360)

mlswg/mls-protocol#360

Keep n ASTrees

The group should keep the last n applications secret trees.

https://github.com/raphaelrobert/maelstrom/blob/ac0ea4d01af7ebe616abf85cd7531a89a3ce4263/src/group/mls_group/mod.rs#L43

Increase upper bound for number of each proposal type per commit (#343)

From 2^16-1 to 2^32-1.

mlswg/mls-protocol#343

[Meta] Implement extensions

Meta issue to implement extensions properly.

• #59
• #99
• #100
• #101

OwnLeaf functions are unrelated to struct

https://github.com/raphaelrobert/maelstrom/blob/b2b72848c9a656f8ab5bf907249a1833414e5908/src/tree/own_leaf.rs#L5-L5

Do not allow changing of the identity field when updating leaf (#404)

mlswg/mls-protocol#404

Include GroupContext in MLSPlaintextTBS only for members (#342)

mlswg/mls-protocol#342

[Meta] Separate ratchet tree

Meta ticket to track separation of the ratchet tree.

Depends on

• #26
• #25
• #24

Handle and test different MLS protocol versions

We will start with a pre-RFC version of MLS and need ways to upgrade from one version to another.
MLS protocol versions were introduced in #382.

• Test with different protocol versions
  • negative tests
  • parallel use of different versions
  • pre-rfc

PathKeypairs should not hold key pairs but again only private keys

https://github.com/raphaelrobert/maelstrom/blob/b2b72848c9a656f8ab5bf907249a1833414e5908/src/tree/path_key_pairs.rs#L7-L7

Rename `confirmation` to `confirmation_tag` (#394)

mlswg/mls-protocol#394

Replace `Vec` with a HashMap in PathKeypairs

https://github.com/raphaelrobert/maelstrom/blob/b2b72848c9a656f8ab5bf907249a1833414e5908/src/tree/path_key_pairs.rs#L5-L5

Check if path_secret has to be optional in new_from_welcome

https://github.com/raphaelrobert/maelstrom/blob/df3d83d45961d47a94fc5a21a8978ee8acc2421c/src/group/mls_group/new_from_welcome.rs#L100-L100

Make the tree in the Welcome optional (#348)

mlswg/mls-protocol#348

Initial init_secret needs to be a random value (#385)

mlswg/mls-protocol#385

Ensure that Application messages are always encrypted (#393)

mlswg/mls-protocol#393

Make composite types 2^32 and make 0 invalid for enums (#387)

mlswg/mls-protocol#387

Don't pull out private keys to create bundles

To create a KeyPackageBundle the private signature key currently needs to get pulled out. This really shouldn't be necessary. Actually, the private signature key probably shouldn't even be retrievable.

https://github.com/raphaelrobert/maelstrom/blob/ac0ea4d01af7ebe616abf85cd7531a89a3ce4263/src/key_packages/mod.rs#L164-L170

Make HPKE setup function name match the spec (#335)

Just a a renaming of some variable in the HPKE draft, but I think the implementation should follow the spec on this (if it doesn't already).

mlswg/mls-protocol#335

Rename identity key to signature key (#403)

mlswg/mls-protocol#403

check if path_secret has to be optional in new_from_welcome

Ensure that paths are included in all commits except maybe Add-only ones (#353)

This was clarified here: mlswg/mls-protocol#353

Enable Commit to cover new proposal types (#389)

mlswg/mls-protocol#389

Generate key package bundle in create_commit

Instead of passing in a new key package bundle we can create it in create_commit. It is returned to the caller for apply_commit.

Use full-size path secrets (#398)

mlswg/mls-protocol#398

Make sure that Proposals are applied in the correct order (#334)

This is mostly an editorial edit which clarifies the order in which proposals are applied. Just make sure we're doing this correctly.

mlswg/mls-protocol#334

Increase upper bound on group size (#339)

It should be 2^32-1 as opposed to 2^16-1 (see PR).

mlswg/mls-protocol#339

Test transcript hash (#388)

mlswg/mls-protocol#388

Capability objects instead of ciphersuits and versions in KeyPackages (#370)

mlswg/mls-protocol#370

Remove verification of group creation process for newcomers (#395)

mlswg/mls-protocol#395

Make extensions spec compliant (#379)

Extensions aren't fully implemented yet.

One issue is: 8 instead of 12, see PR.

mlswg/mls-protocol#379

Rename DirectPath to UpdatePath (#391)

mlswg/mls-protocol#391

Rely on HPKE where possible (not individual primitives) (#338)

This might be already the case. If so, feel free to close.

mlswg/mls-protocol#338

Enforce direct-path tree invariant

Enforce that path keys are only on the direct path.

Why does verify_integrity require any arguments?

https://github.com/raphaelrobert/maelstrom/blob/df3d83d45961d47a94fc5a21a8978ee8acc2421c/src/group/mls_group/new_from_welcome.rs#L94-L94

cc @raphaelrobert

Use the KDF provided by HPKE (#364)

mlswg/mls-protocol#364

Test node hashes (#352)

mlswg/mls-protocol#352

Reorder key schedule inputs (#361,#362)

mlswg/mls-protocol#362

(Also take care to call Derive-Secret properly as per mlswg/mls-protocol#361)

Agile Credentials

Credential can currently only handle basic credentials of type ed25519. We need to

• Make Credential handle basic and x509 credentials (x509 should just panic for now)
• Make BasicCredential know its key type for use outside of MLS
• Make the ciphersuite in the Identity play nicely with the key type of the BasicCredential
• Implement P256 basic credentials

[Meta] Separate tree logic

Meta ticket to track separation of the tree logic.

Use node secrets in addition to path secrets (#397)

mlswg/mls-protocol#397