MLS Group Encryption Explained: How RFC 9420 Secures Group Chats

Encrypting a conversation between two people is a solved problem. Encrypting a conversation between two hundred people, some of whom join late, some of whom leave, and one of whom may have a stolen phone, is a very different one. For years the industry handled groups with clever workarounds. In July 2023 the IETF published a proper answer: Messaging Layer Security, or MLS, standardised as RFC 9420.

VOIDEX uses MLS for group conversations in VOIDEX Messenger and for private VOIDEX Channels. This article explains what MLS does, why the older approaches strain at scale, and what the words "epoch", "tree" and "post-compromise security" actually mean for the people in the room.

Why pairwise encryption does not scale

The simplest way to encrypt a group is to pretend it is not a group. Every message is encrypted separately to every member, using the same one-to-one channel you would use for a private chat. With five people, you encrypt each message four times. With five hundred, you encrypt it four hundred and ninety nine times, per device, every time you send a line.

That is not only slow. It also makes group state fragile. Every sender must agree with every other sender about who is in the group, and there is no single, shared record of membership that all devices can check. Two members can quietly disagree about who is present, and nobody notices.

The common shortcut is the "sender key". Each member generates one key for their own messages, hands it to everyone else over pairwise channels once, and then encrypts each message only once. It is efficient, and it is used by respected products. Its weakness is recovery. If a device is compromised and an attacker copies its sender keys, the attacker can keep reading until those keys are replaced, and replacing them means another round of pairwise distribution to everyone. In a large, busy group that healing is expensive, so in practice it happens rarely.

What a group really needs is the property we already expect from good one-to-one encryption: keys that move forward constantly, and a cheap way to lock an intruder back out.

Trees of keys

MLS solves the scaling problem with a data structure rather than brute force. Every member sits at a leaf of a binary tree. Each node above the leaves holds a key pair, and a member knows the private keys of every node on the path from their own leaf up to the root. The root secret is shared by the whole group, and from it everyone derives the keys that actually encrypt messages.

The trick is in how the tree changes. When a member wants to refresh their keys, they generate new key pairs for every node on their path to the root. They then encrypt each new node secret to the other side of the tree at that level, so that exactly the right people can compute the new root. The RFC calls this machinery TreeKEM.

The effect is dramatic. In a balanced tree of a thousand members, a path from leaf to root is only about ten nodes long. Refreshing the whole group's secret costs roughly ten encryptions, not a thousand. That logarithmic cost is why MLS can offer strong guarantees to groups that would make pairwise schemes groan.

Epochs: one shared state, one moment at a time

MLS gives the group a notion of time. The group moves through a sequence of epochs. Within one epoch, everyone agrees on the exact membership list and on one shared secret. Any change moves the group to a new epoch.

Changes happen in two steps:

1. Proposals suggest something: add this member, remove that one, update my keys.
2. A commit gathers proposals, applies them, refreshes the committer's path in the tree, and announces the new epoch.

Every member processes the same commit and arrives at the same new secret. Each epoch also carries a hash of the group's state, so a member whose view has drifted from everyone else's will find that their keys simply do not match. Disagreement about membership stops being a silent risk and becomes a detectable error.

Epochs also make joining and leaving precise. A new member receives a Welcome message that gives them the secrets for the current epoch only. They cannot read what was said before they arrived. A removed member is left out of the new path secrets, so they cannot read what is said after they leave.

Forward secrecy for groups

Forward secrecy means that stealing today's keys does not unlock yesterday's messages. MLS delivers it on two levels.

Across epochs, old epoch secrets are deleted once the group moves on. Within an epoch, MLS runs a secret tree that derives a fresh key for each message from each sender, ratcheting forward and discarding what was used. A device that is seized next month holds no keys for last month's conversation.

This is the same principle behind the ratchet that protects one-to-one chats, which we cover in forward secrecy and the double ratchet. MLS carries it into rooms of any size.

Post-compromise security: locking the intruder out

Forward secrecy looks backwards. Post-compromise security looks forwards. Suppose an attacker did copy a member's keys at some moment. How long can they keep listening?

In MLS the answer is: until that member, or anyone who removes and re-adds them, commits a key update. The update replaces every secret on the member's path with values the attacker never saw, and the group moves to an epoch the attacker cannot compute. Because an update costs only a logarithmic number of encryptions, it is cheap enough to do routinely, which is exactly what makes the guarantee meaningful in practice rather than only on paper.

This is the property sender-key designs struggle with. MLS was built around it.

What MLS does not do on its own

A standard is a foundation, not a finished building. Three honest limits are worth knowing.

• Identity is out of scope. MLS assumes each member's credential is genuine. If a server could quietly substitute a key for someone, it could insert itself. That is why key verification matters. VOIDEX appends every device key change to a public, append-only Merkle log in the style of Certificate Transparency, and clients refuse keys that are not in it. We explain that system in key transparency.
• The server still routes messages. MLS relies on a delivery service to pass commits and messages between devices. It cannot read them, but it does see that traffic flows. We discuss what that means in metadata is the message.
• Ordering matters. Two members committing at once must be resolved so everyone lands in the same epoch. The protocol defines how, and implementations must follow it carefully.

MLS across the industry

MLS is no longer an academic proposal. It is an IETF standard with an accompanying architecture document, and it is spreading. In March 2025 the GSMA published RCS Universal Profile 3.0, the first version of the carrier messaging standard to specify end-to-end encryption, and it chose MLS to do it, with Apple and Google among the contributors, as the GSMA announced. When the organisations behind the default texting apps of billions of phones agree on a group encryption protocol, that is a signal about where the field is going.

How VOIDEX uses MLS

In VOIDEX, groups and private channels run on MLS. When you create a group in VOIDEX Messenger, or a private channel in VOIDEX Channels, the keys are created on members' devices, and VOIDEX servers store only public keys and ciphertext. Joins, removals and key updates move the group through epochs exactly as the standard describes, so a new member cannot read the room's past and a removed member cannot read its future.

One-to-one conversations use a different, tighter design: a hybrid post-quantum key agreement combining X25519 and ML-KEM-768, followed by a double ratchet with post-quantum re-keying, so each direct message has its own key. Groups get MLS because MLS is the protocol built for groups.

We are equally clear about what is not encrypted. VOIDEX Channels come in two kinds. Private channels are end-to-end encrypted. Public channels are not, because they are designed to be read by anyone who opens them, much like public posts in VOIDEX Space. VOIDEX labels every public channel as public and not encrypted, so nobody mistakes a town square for a sealed room. A security product earns trust by being precise about its boundaries, not by blurring them.

Everything else is open to inspection. The cryptographic core is published as open source, and the full architecture, including the parts VOIDEX can and cannot see, is set out in the public security report.

The takeaway

Group chat is where most people actually talk: families, teams, studios, crews. For a long time it was also where encryption quietly got weaker, because the tools for one-to-one conversations did not stretch. MLS changes that with a tree of keys, a shared notion of epochs, and cheap, routine healing after a compromise.

The room gets bigger. The guarantees no longer get smaller.

VOIDEX is invite-only. Request access, or read the full VOIDEX security report to see how every layer fits together.

Sources

• IETF, RFC 9420: The Messaging Layer Security (MLS) Protocol, July 2023: https://www.rfc-editor.org/rfc/rfc9420
• GSMA, RCS Encryption: A Leap Towards Secure and Interoperable Messaging, March 2025: https://www.gsma.com/newsroom/article/rcs-encryption-a-leap-towards-secure-and-interoperable-messaging/