Explainer · Encryption
What is MLS encryption? MLS vs Signal Protocol vs Matrix Megolm
MLS, Messaging Layer Security, is the IETF standard for end-to-end encrypted group messaging, published as RFC 9420 in July 2023. It gives every member of a group the same secret for each version of the group, derived from a tree of keys, so adding or removing a member costs work that grows roughly with the logarithm of the group size. Unlike the Signal Protocol, it is designed for groups from the start; unlike Matrix’s Megolm, it provides post-compromise security as well as forward secrecy.
Updated
- Standard
- RFC 9420, IETF, July 2023
- Solves
- Group key agreement for end-to-end encryption
- Key structure
- A ratchet tree of keys (TreeKEM)
- Security properties
- Forward secrecy and post-compromise security
- Unit of membership
- A device, not a person
- In Enclessa
- Direct and group direct messages, via OpenMLS
What problem does MLS solve?
End-to-end encryption between two devices is a solved problem; a group is not. Every member of an encrypted group needs the same key, nobody else may have it, and the key has to change whenever somebody joins or leaves, or a removed member could keep reading. The older approach is to encrypt each message separately for every recipient device, or to hand each device a key over one-to-one channels. Both work, and both make each membership change cost work in proportion to the number of devices in the group. MLS, standardised by the IETF as RFC 9420, replaces this with group key agreement: the members agree on one shared secret for each version of the group, called an epoch, and every join, removal or key update moves the whole group to a new epoch together. All members also agree on who is in the group, so a server cannot quietly show different members different lists.
How does TreeKEM make large groups practical?
MLS arranges the group’s keys as a binary tree, called the ratchet tree; the mechanism is known as TreeKEM. Each device holds a leaf, and each node above the leaves holds a key pair known only to the members underneath it. To change the group secret, a member generates fresh keys along the path from its leaf to the root and encrypts each new secret to the sibling branch next to that path, rather than to every device individually. In a well-populated tree that path has a length proportional to the logarithm of the group size, so a group of a thousand devices needs around ten encryptions for an update rather than a thousand. Removals can leave blank nodes that make a later update more expensive until the tree is refilled, so logarithmic is the typical cost rather than a guarantee. The design is what lets MLS aim at groups of thousands of members.
What do forward secrecy and post-compromise security mean in MLS?
Forward secrecy means that a key stolen today cannot decrypt messages sent before the theft. MLS achieves it by deriving the keys for each message from the epoch secret in one direction only, and deleting them after use, so an attacker holding the current state cannot walk backwards. Post-compromise security is the opposite direction: once a compromised device is removed, or simply updates its keys, fresh randomness enters the group secret and the attacker who held the old state is locked out of new messages. The Signal Protocol’s Double Ratchet provides both properties between two parties; MLS provides both for a whole group. Both properties depend on real behaviour: old keys have to be deleted on the device, and a compromised device has to be identified and removed or has to update. That is why MLS treats every device, rather than every account, as a separate member of the group.
How is MLS different from the Signal Protocol?
The Signal Protocol is the family of specifications Signal publishes, chiefly an initial key agreement, X3DH and its post-quantum successor PQXDH, followed by the Double Ratchet. It was designed for two parties and provides forward secrecy and post-compromise security between them. Groups are built on top of those pairwise sessions: a sender either encrypts each message for every member device or distributes a sender key to each of them over the pairwise channels, and either way the cost of a membership change grows with the number of devices. MLS starts from the group instead. Its tree structure keeps the cost of changes low, and every member verifies the same group state in every epoch. The Signal Protocol is not an IETF standard; MLS is. Both are well analysed and widely deployed; the choice between them matters most for large groups and for teams that want an open standard.
How is MLS different from Matrix’s Megolm?
Megolm is the group encryption algorithm in the Matrix specification. Each sender keeps its own ratchet session for a room and shares it with every recipient device over Olm, Matrix’s one-to-one channel. That design suits a federated network and makes sharing history easy: a device given the session from a certain point can read everything sent after it. The Matrix specification is candid about what that costs. Megolm offers only partial forward secrecy, because a stored session state can decrypt messages from its position onwards, and it provides no backward secrecy within a session: whoever obtains a session state can read every later message in it until the sender starts a new session. Clients mitigate this by rotating sessions periodically and when membership changes. MLS gives the whole group one evolving secret instead, with forward secrecy and post-compromise security built into the protocol.
How does Enclessa use MLS?
Enclessa encrypts direct messages and group direct messages end to end with MLS, through OpenMLS, an open-source Rust implementation of RFC 9420. The same compiled code runs in every client; the web client runs it as WebAssembly. Each device is a separate member with its own key, so adding a device is visible to the conversation and revoking one re-keys it. Devices are cross-signed, and safety numbers let two people check out of band that they are talking to each other’s real devices. The server implements only the MLS delivery service: it orders and forwards handshake messages and holds no key that opens a message. Channels are deliberately different: they are managed rooms the server can read, so that search, retention and export work, and every room shows which kind it is. OpenMLS has had external review; Enclessa’s own integration has not yet been through a third-party audit.
What does MLS not protect?
MLS protects the content of messages between the devices in a group. It does not hide metadata by itself: the delivery service still sees which devices are in which group, when messages are sent and how large they are. It does not protect a device that is compromised while it is a member; post-compromise security helps only after that device is removed or updates its keys. It does not protect what a recipient copies, forwards, screenshots or backs up in plaintext, and it cannot stop a legitimate member from sharing what they read. Nor does it decide who should be in the group: the protocol authenticates credentials, and deciding which credentials to trust is the application’s job, which is why device verification matters. Finally, MLS is a specification. Its guarantees hold only in an implementation that follows it correctly, which is why implementations are reviewed and why a shared, audited library is safer than a new one.
MLS, the Signal Protocol and Megolm side by side
Each row is taken from the protocol’s own specification, linked below. The Signal column describes the pairwise protocol and the usual ways groups are built on it.
| MLS compared with the Signal Protocol and Matrix Megolm | MLS | Signal Protocol | Megolm (Matrix) |
|---|---|---|---|
| Specified by | IETF, RFC 9420 (2023) | Signal’s published specifications (X3DH, PQXDH, Double Ratchet) | The Matrix specification |
| Designed for | Groups, from two members to thousands | Two parties; groups built on top | Group rooms in a federated network |
| How the group shares keys | One group secret per epoch, from a ratchet tree | Pairwise sessions, used to fan out messages or sender keys | Each sender’s session, shared with every device over Olm |
| Cost of a membership change | Typically logarithmic in the group size | Grows with the number of member devices | A new session shared with every device |
| Forward secrecy | Yes | Yes, between two parties | Partial, by the specification’s own account |
| Post-compromise security | Yes, after an update or removal | Yes, between two parties | Not within a session; sessions are rotated |
| All members agree on the group state | Yes, verified every epoch | Left to the application | Left to the room state kept by servers |
Where are these protocols specified?
The primary sources behind every statement on this page. Read the specification rather than a summary of it — including this one.
Keep reading
Questions
MLS encryption: common questions
- Neither is simply better. The Signal Protocol is a mature, heavily analysed design for two parties, with groups built on top of pairwise sessions. MLS is an IETF standard designed for groups from the start, so membership changes stay cheap as groups grow and every member agrees on the group state. For large groups and for an open standard, MLS has the advantage.
- Matrix’s end-to-end encryption is specified with Olm for one-to-one channels and Megolm for rooms. The Matrix specification describes Megolm as offering only partial forward secrecy and no backward secrecy within a session, mitigated by rotating sessions. Check the current Matrix specification for the status of any MLS work.
- MLS is built around cipher suites, so its security depends on the algorithms a deployment chooses. The cipher suites defined in RFC 9420 use classical elliptic-curve cryptography; post-quantum suites are a matter of extensions and newer work rather than of the original RFC.
- Direct messages and group direct messages. Channels are managed rooms that the server can read, so that search, retention and export work, and each room shows its mode. A room cannot be converted from one mode to the other.
Your team. Your keys. Your continent.
Create a workspace in a minute. Free for up to ten people, forever.