Adding a third person to an encrypted conversation seems like it should be simple. It isn't. The cryptographic properties that make 1:1 messaging secure — forward secrecy, post-compromise security, deniability — become significantly harder to preserve as group size grows.
When Signal introduced group chats, they faced a problem that doesn't exist in 1:1 messaging: how do you efficiently encrypt a single message for many recipients while preserving strong security guarantees? The naive answer — encrypt the message separately for each recipient — works but scales poorly.
The Naive Approach: Pairwise Encryption
The simplest group messaging implementation is pairwise encryption: the sender establishes a separate secure channel with each group member and sends the message individually to each one. This provides full forward secrecy because each channel uses the Signal Protocol (Double Ratchet), which rotates keys on every message.
Signal actually used this approach for groups in its earlier implementations. The security properties are strong — each pairwise channel is as secure as a 1:1 conversation. But the cost is linear scaling: message overhead grows proportionally with group size. For a group of 100 people, sending one message requires 100 individual encryptions, 100 individual network deliveries, and 100 individual ratchet advances.
Sender Keys: Signal's Group Optimization
Signal's current group implementation uses Sender Keys to solve the scaling problem. Each group member generates a Sender Key — a chain key used to derive a sequence of encryption keys for that member's outgoing messages. The Sender Key is distributed to each group member individually, but after that initial distribution, the sender encrypts each message once with the current key from their chain.
This reduces message overhead from O(N) to O(1) for subsequent messages. The tradeoff is in forward secrecy characteristics: Sender Keys advance forward through a hash chain, providing forward secrecy against passive observers. But they don't provide the full Double Ratchet's break-in recovery — if a member's current state is compromised, the attacker can decrypt subsequent messages until the chain is reset.
Key insight: Sender Keys provide forward secrecy but weaker post-compromise security. This is an explicit tradeoff for group scalability.
The Member Addition and Removal Problem
The hardest problem in secure group messaging isn't encrypting messages — it's managing membership changes securely.
When a new member joins a group, they should not be able to decrypt messages sent before they joined — a property called forward secrecy for new members. When a member is removed, they should not be able to decrypt future messages — called post-remove secrecy. Achieving the latter requires rotating the group key after removal, which for a group of 1,000 members means 999 individual key distributions.
MLS: A Cryptographically Sound Group Protocol
Messaging Layer Security (MLS, RFC 9420) was designed from first principles to solve group messaging security at scale. Rather than Sender Keys' O(N) key distribution on membership change, MLS uses a binary tree structure where group members occupy the leaves and internal nodes hold intermediate keys.
This "ratchet tree" allows key updates to propagate efficiently. When a member updates their key material (a "commit"), only the nodes on the path from their leaf to the root need updating. In a balanced tree with N members, that's O(log N) operations rather than O(N) — roughly 10 operations for 1,000 members instead of 999.
| Protocol | Message Cost | Membership Change Cost | Post-Compromise Security |
|---|---|---|---|
| Pairwise (Signal v1) | O(N) | O(N) remove | Strong |
| Sender Keys (Signal current) | O(1) | O(N) re-distribute | Weaker |
| MLS (RFC 9420) | O(1) | O(log N) tree update | Strong |
Epochs and the Concurrent Commit Problem
MLS introduces the concept of an epoch — a version of the group state. Every time the group membership changes or key material is updated, the group advances to a new epoch. Messages are encrypted under the epoch key valid at the time of sending.
This provides a clean boundary for forward secrecy, allows recovery from device compromise by rotating to a new epoch, and creates a cryptographic audit trail of group state changes.
The challenge: in a distributed system, two members might independently try to advance the epoch simultaneously — a "concurrent commit." MLS has a defined resolution mechanism, but it adds complexity that Sender Key approaches avoid.
What Applications Are Deploying
As of 2026, MLS adoption is growing. WhatsApp announced MLS adoption. Apple Messages began using MLS for group chats. Matrix has an MLS implementation in development.
Haven uses MLS for encrypted group chat, specifically for the O(log N) membership change overhead and strong post-compromise security guarantees. Signal continues using Sender Keys for large groups — both positions are defensible depending on group size distributions and adversary models.
What This Means for Users
Questions worth asking about any secure group messaging app:
- Does removing a member prevent them from reading future messages?
- Can a new member read history from before they joined?
- Is the group protocol documented and independently audited?
- What happens if one member's device is compromised?
Forward secrecy in 1:1 contexts is well-understood; in group contexts it requires explicit design choices that vary significantly between implementations.
Originally published at havenmessenger.com
