Modern encrypted messaging sits on one of two foundations: OpenPGP (used by email, built in 1991) or the Signal Protocol (used by Signal, WhatsApp, and many others, developed around 2013). Both were designed primarily for 1:1 communication and adapted, with varying success, to work in groups.
The adaptations show their age. MLS — Messaging Layer Security — is what happens when cryptographers spend years designing group encryption from scratch, informed by two decades of watching the adaptations fail.
The Core Problem: Groups Are Not Scaled 1:1 Chats
When you add a member to a Signal group, the protocol needs to ensure that new member can read future messages but cannot read past ones (forward secrecy), and that if a member's device is compromised, the damage is bounded (post-compromise security). Achieving both simultaneously, for an arbitrary number of members changing over time, requires careful key management.
Signal's approach uses what's called "Sender Keys" — each member derives a sending key and distributes it to all other members. This works, but it has a fundamental scaling problem:
- Adding one member to an N-person group requires N key update messages
- Removing one member requires rotating the sender key for every remaining member
- For large groups, this creates O(N) overhead on every membership change
For a 10-person group this is fine. For a 500-person group, removing a single member triggers 499 key distribution messages. WhatsApp, which uses Signal Protocol with groups of thousands, has had to build substantial infrastructure workarounds.
TreeKEM: MLS's Solution
MLS uses a construction called TreeKEM — a binary tree where each leaf represents a group member and each internal node holds a derived key. Membership changes propagate through the tree in O(log N) operations instead of O(N).
When a member is added or removed, only the keys along the path from that leaf to the root need updating. In a group of 1,000 members, that's about 10 operations. The efficiency gains at scale are significant — but the real advantage isn't performance, it's the cryptographic properties this structure makes possible.
Forward Secrecy and Post-Compromise Security
MLS provides two security properties simultaneously that most group messaging implementations struggle to combine:
Forward secrecy means that compromising a key today does not reveal past messages. Old keys are deleted after use; an attacker who captures your device tomorrow cannot recover conversations from last week.
Post-compromise security (also called "future secrecy" or "break-in recovery") means that even if a key is compromised, the damage is bounded in time. MLS performs regular key updates (called "commits") that incorporate fresh randomness, so a device that was briefly compromised heals cryptographically — future messages are safe even if past state was exposed.
Most encrypted messaging gives you one or the other. Signal Protocol gives forward secrecy for 1:1 chats (via the Double Ratchet), but group chats using Sender Keys provide weaker guarantees. MLS gives both, verifiably, for groups of any size.
It's a Standard, Not a Product
The IETF (Internet Engineering Task Force) standards process is slow, rigorous, and adversarial. RFC 9420 was in development for five years, with contributions from cryptographers at Apple, Cisco, Google, Meta, Mozilla, Twitter, and Wire. The protocol has been formally analyzed and proven secure under standard cryptographic assumptions.
This matters for a reason that's easy to miss: interoperability. The Signal Protocol is a proprietary design maintained by a single organization. It's excellent, but a Signal message can only be decrypted by Signal. MLS is a public standard — any application that implements RFC 9420 can interoperate with any other.
The EU's Digital Markets Act, which took effect in 2024, requires large messaging platforms to offer interoperability APIs. MLS is the protocol those APIs are being built around. The fragmentation of encrypted messaging — where Signal users can't talk to WhatsApp users who can't talk to iMessage users — has a realistic path to resolution through MLS.
Who Is Deploying It
WhatsApp announced MLS deployment in late 2023 for its 2 billion users, making it the largest real-world deployment of the protocol by orders of magnitude. Cisco Webex has implemented MLS for enterprise messaging. Several Matrix clients are building MLS support.
Haven implements MLS via OpenMLS, an open-source Rust library maintained by the OpenMLS working group. The cryptographic operations run in a Rust library compiled to native code on Android and WebAssembly on the web — the same code path regardless of platform, which eliminates an entire class of platform-specific security bugs.
MLS vs. Signal Protocol: A Practical Comparison
This isn't a case where one is unambiguously better. They address different use cases well:
- 1:1 chats: Signal's Double Ratchet is elegant and battle-hardened. MLS adds overhead that isn't justified for two-person conversations.
- Small groups (2–20 people): Both work. MLS has better theoretical properties; Signal Protocol has more deployed verification behind it.
- Large groups (20+): MLS's O(log N) operations become important. Signal-style sender keys create real scalability and security problems at this scale.
- Frequently changing membership: MLS handles additions and removals cryptographically cleanly. Signal-style approaches require costly key rotations.
The Verification Question
One often-overlooked aspect of MLS is its support for cryptographic group state verification. Each member maintains a Ratchet Tree — a local representation of the group's key structure. Members can verify that the group state they see matches what other members see, providing a form of tamper evidence that's difficult to achieve in other group encryption schemes.
This matters for high-trust communications where you need to be confident that your view of "who's in this conversation" matches everyone else's — and that an attacker hasn't silently added themselves.
The Takeaway
MLS is not a replacement for all encrypted messaging. It's a purpose-built standard for the use case that existing protocols handle worst: secure, efficient, scalable group communication with strong forward secrecy and post-compromise security guarantees.
If you use encrypted group messaging — for team communication, family groups, or anything where the membership changes over time — the protocol underneath that messaging matters more than most users realize. An IETF-standardized, formally verified protocol is a meaningfully stronger foundation than an adapted 1:1 protocol.
Haven's chat is built on MLS. The email side uses PGP for interoperability with the broader world. The two together cover the communication patterns most people actually use.