Start with the thing that works. The Double Ratchet protects a one-to-one conversation: every message advances a chain of keys, so a key captured today does not unlock yesterday's messages or tomorrow's. It is the core of Signal's pairwise encryption and the model most modern messengers copied. The problem is that the Double Ratchet describes a channel between exactly two parties.
So how do you encrypt a message for a group of fifty? The obvious approach is to treat the group as a bundle of pairwise channels. You have a Double Ratchet session with each of the other forty-nine members, so you encrypt the message forty-nine times, once per session, and send forty-nine ciphertexts. This is usually called pairwise fan-out or client-side fan-out, and it is genuinely secure. It is also genuinely expensive.
Why Pairwise Fan-Out Does Not Scale
The cost is linear in group size, paid by the sender, on every single message. In a group of N people, sending one message means N minus one encryption operations and N minus one ciphertexts pushed to the server. For a five-person family group that is trivial. For a 500-person community group it means every "ok thanks" turns into 499 separate encrypted payloads.
That cost lands hardest exactly where messaging apps live: phones, with limited battery, intermittent radios, and metered data. A user on a slow connection typing into a large group would feel the device work for every message. Multiply that across millions of users and the server bandwidth alone becomes a serious operational number.
Pairwise fan-out gives strong per-message guarantees but costs O(N) per message sent. Sender Keys gives O(1) per message sent but weakens the guarantee that one key compromise cannot decrypt a whole conversation. Group encryption is the art of choosing where on that line to sit.
The Sender Keys Idea
Sender Keys flips the model. Instead of encrypting each message once per recipient, each member generates a single symmetric sender key for the group. When you join a group, you distribute your sender key to every other member, and you do that distribution over the pairwise encrypted channels you already have. That one-time cost is O(N), but you pay it on join, not on every message.
From then on, sending a message is cheap. You encrypt the message once with your own sender key, push one ciphertext to the server, and the server fans it out to everyone. Every member already holds your sender key, so every member can decrypt it. The expensive per-recipient work happened once at setup; the steady state is one encryption and one upload per message regardless of whether the group has five members or five hundred.
The sender key is not static. It is run through a hash-based ratchet, typically built on a key derivation function, so each message uses a fresh derived key and the chain moves forward. This preserves forward secrecy within a sender's own message stream: capturing the current chain state does not reveal the symmetric keys used for earlier messages, because a one-way KDF cannot be run backward.
What You Give Up
Here is the honest part. Sender Keys weakens post-compromise security, which is the property that lets a conversation heal after a device is compromised. With the Double Ratchet, a Diffie-Hellman step on each round mixes in fresh randomness, so even if an attacker steals your keys, the next exchange can lock them back out. A hash ratchet alone cannot do that. It only moves forward; it never injects new entropy from the other side.
The practical consequence: if an attacker captures a member's sender key state, they can decrypt that member's future messages until the key is rotated. Sender Keys implementations handle this by rotating keys on membership change. When someone leaves the group, everyone generates and redistributes new sender keys, so the departed member cannot read anything sent afterward. But between rotations, a compromised key keeps paying out.
| Property | Pairwise fan-out | Sender Keys |
|---|---|---|
| Cost per message sent | O(N) encryptions | O(1) encryption |
| Forward secrecy | Strong | Within each sender's stream |
| Post-compromise recovery | Per-message DH heals | Only on key rotation |
| Cost of a member leaving | Drop one session | Full key rotation, O(N) |
The Member-Removal Problem
Membership churn is where Sender Keys shows its seams. Removing a member is not just an access-control flag on the server. To actually stop the removed person from reading new messages, every remaining member has to throw away their old sender key and distribute a new one. In a busy group with frequent joins and leaves, that rotation cost adds up, and any implementation bug that skips a rotation leaves a removed member able to keep reading.
This is the exact problem that Messaging Layer Security (MLS, RFC 9420) was designed to fix. MLS uses a tree-based key schedule so that adding or removing a member, and rotating the group secret, costs O(log N) instead of O(N), while still giving genuine post-compromise security across the whole group. It is the structural upgrade over Sender Keys for groups that change membership often or need stronger healing guarantees.
So Which One Is Right?
None of these is universally best. They are points on a curve.
- Pairwise fan-out fits small, stable groups where per-message O(N) is cheap and you want the strongest possible per-message guarantees.
- Sender Keys fits large groups with light churn, where the O(1) send cost is the deciding factor and rotation-on-leave is acceptable.
- MLS fits groups that need both scale and strong recovery, accepting more protocol complexity for O(log N) membership operations.
The reason Sender Keys is so widespread is that for the average group chat the trade is reasonable: most groups are not under active device compromise, most messages do not need per-message healing, and the bandwidth savings are enormous. The reason it is not the end of the story is that "most groups, most of the time" is not the threat model that high-risk users live in.
Where Haven Fits
Haven uses MLS (RFC 9420) for group messaging rather than a Sender Keys design, because we wanted the stronger membership and recovery properties for groups that change over time. That choice costs more protocol complexity, and it is a trade we made deliberately rather than a marketing line. If you are evaluating any secure group messenger, the question worth asking is not "is it encrypted" but "what happens to old messages when someone is removed, and how fast does the group recover after a compromise."