Lupyd.
Group Security Group Chat Security

Why Securing Group Chats Takes More Than Just Direct Message Encryption

Why protecting conversations with many people is vastly more complex than direct messages, and how modern group ratchets solve it.

S

Sri Pranav Tene, CEO

Lupyd

May 25, 2026
•
9 min read
Why Securing Group Chats Takes More Than Just Direct Message Encryption

TreeKEM Logarithmic Key Agreement Architecture

Group Epoch Secret [ Root Key (Group Epoch Secret) ]
[ Node L ]
[ Node R ]
[ Alice ] Leaf 0
[ Bob ] Leaf 1
[ Carol ] Leaf 2
[ David ] Leaf 3
Adding or removing a participant updates only their copath (O(log N)), ratcheting the group epoch instantly.

Replacing pairwise fanout with a balanced binary tree slashes group state complexity from O(N) down to O(log N).

Securing a direct conversation between two people is a mature, well-solved engineering problem. Protocols like the Signal Double Ratchet deliver robust forward secrecy and post-compromise security for direct messaging. But the moment you add a third, tenth, or fiftieth person to the conversation, the entire mathematical model changes dramatically.

The Problem with Pairwise Encryption in Groups

In traditional end-to-end encrypted messengers, groups are implemented through client-side fanout. If you are in a group with 100 members, your phone must encrypt your message 99 separate times (once for each participant's pairwise session key) and upload 99 individual ciphertexts to the relay.

This approach has catastrophic scaling limitations:

  • Bandwidth & Battery Drain: Sending a simple 10KB photo to a 200-person group requires uploading 2MB of redundant ciphertexts from your mobile connection.
  • State Desynchronization: If two members send messages simultaneously while offline devices reconnect, resolving message ordering and ratchet states across hundreds of pairwise sessions leads to frequent decryption errors.

The Join / Leave Conundrum: Backward and Forward Secrecy

Group membership is dynamic. People join project teams, and departing contractors are removed. In a cryptographically secure system, membership changes must fulfill two strict criteria:

  • Forward Secrecy (Upon Eviction): When a member is removed from a group, they must be mathematically incapable of decrypting any subsequent messages, even if they continue intercepting network traffic.
  • Backward Secrecy (Upon Addition): When a new colleague joins a project channel, they must not be able to decrypt past conversations that took place before their arrival.

How TreeKEM Solves the Scalability Bottleneck

The IETF Messaging Layer Security (MLS) protocol replaces pairwise fanout with a balanced binary tree structure known as TreeKEM:

Instead of managing $N$ individual keys, all members share an epoch root secret derived from the tree. When someone joins or leaves, only the nodes along that member's path to the root are updated. This slashes computational and bandwidth complexity from linear $O(N)$ down to logarithmic $O(log N)$. In a group of 1,000 members, updating the group epoch requires communicating with approximately 10 tree nodes rather than 1,000 individual peers.

Key Takeaways
  • ✓ Pairwise double-ratchet protocols (like Signal) scale at O(N) per message and O(N^2) for membership updates, causing severe battery and bandwidth lag in large groups.
  • ✓ When a member leaves a secure group, immediate cryptographic eviction is mandatory; otherwise, former members could read subsequent messages.
  • ✓ The IETF Messaging Layer Security (MLS) protocol introduces TreeKEM, scaling key derivation down to logarithmic O(log N) complexity.
  • ✓ Decentralized group governance allows member devices to mathematically verify administrative proposals before ratcheting the group epoch.
  • ✓ WASM compilation enables browsers and lightweight desktop clients to execute MLS state transitions at native speeds.
Open Source

Explore Lupyd on GitHub

Inspect our open-source repositories, cryptography libraries, and client tools on GitHub.

Explore Lupyd on GitHub