End-to-End Encryption

The Problem

Users expect their private messages, files, and data to be protected from everyone — including the service provider. End-to-end encryption (E2EE) ensures that only the communicating parties can read the content; the server handles encrypted blobs it cannot decrypt. Implementing E2EE requires solving key exchange (how do two parties agree on a shared secret over an insecure channel?), forward secrecy (compromising today’s key shouldn’t reveal past messages), multi-device synchronization (encryption keys across phone, laptop, tablet), and group encryption (efficiently encrypting for N participants). The server must be designed as an untrusted relay.

Architectural Approaches

Architecture

Loading diagram...

Key Components

Data Model

Loading diagram...

X3DH Key Agreement

The Extended Triple Diffie-Hellman (X3DH) protocol establishes a shared secret between two parties, even when one is offline.

Key types per user:

• Identity Key (IK): Long-term key pair, generated once per device
• Signed Pre-Key (SPK): Medium-term key pair, rotated monthly, signed by IK
• One-Time Pre-Key (OPK): Single-use key pair, uploaded in batches of 100

Protocol flow (Alice initiates session with offline Bob):

1. Alice fetches Bob’s pre-key bundle from the server: IK_B, SPK_B, OPK_B
2. Alice generates an ephemeral key pair: EK_A
3. Alice computes four DH exchanges:
   • DH1 = DH(IK_A, SPK_B)
   • DH2 = DH(EK_A, IK_B)
   • DH3 = DH(EK_A, SPK_B)
   • DH4 = DH(EK_A, OPK_B) — optional, provides forward secrecy
4. Shared secret = KDF(DH1 || DH2 || DH3 || DH4)
5. Alice sends her initial message with IK_A and EK_A public keys
6. Bob computes the same DH exchanges on his side to derive the same shared secret

The one-time pre-key (OPK) is deleted after use, ensuring that even if long-term keys are compromised later, this specific session key cannot be derived retroactively.

Loading diagram...

Double Ratchet Algorithm

After X3DH establishes the initial shared secret, the Double Ratchet provides ongoing forward secrecy and break-in recovery.

Two ratchets:

1. Symmetric ratchet (chain key): After each message, the chain key is ratcheted forward using a KDF: chain_key[n+1] = KDF(chain_key[n]). Each message gets a unique message key derived from the chain. Old chain keys are deleted, providing forward secrecy.
2. Asymmetric ratchet (DH ratchet): On each message exchange, both parties generate new DH key pairs and perform a new DH exchange. This “ratchets” the root key forward, providing break-in recovery — even if an attacker compromises the current state, future messages are safe once a new DH exchange occurs.

Combined operation: Every message from Alice includes a new public DH key. When Bob sends a reply, he performs a DH with Alice’s latest key, advancing the root ratchet. Both parties maintain sending and receiving chains that ratchet forward with each message.

Key deletion: The critical security property. After deriving a message key, delete it. After advancing the chain, delete the old chain key. This means a compromised device can only decrypt the current message, not past ones.

Out-of-order messages: The Double Ratchet handles out-of-order delivery by caching skipped message keys (within limits). If message #5 arrives before #4, the key for #4 is stored temporarily so it can be decrypted when it arrives.

Group Encryption Challenges

Encrypting for a group of N members is fundamentally harder than 1:1 encryption.

Naive approach: Encrypt the message separately for each member using their pairwise session. Cost: O(N) encryptions per message. Fine for small groups (<50) but impractical for large groups.

Sender Keys (Signal’s approach for groups): Each member generates a “sender key” and distributes it to all group members via pairwise encrypted channels. Messages are encrypted once with the sender key, and all members can decrypt. Cost: O(1) encryption per message, O(N) for sender key distribution.

Limitations of Sender Keys:

• Adding a member requires distributing all existing sender keys
• Removing a member requires ALL members to generate new sender keys (the removed member knows the old keys)
• No forward secrecy within the group — compromising a sender key reveals all past group messages encrypted with it

MLS (tree-based): Uses a binary tree structure where each member is a leaf. The group secret is at the root. Adding/removing a member requires updating O(log N) nodes in the tree. Much more efficient for large groups and provides better forward secrecy guarantees than Sender Keys.

Real-World Examples

Architectural Tradeoffs

# Learn the System Design of: End-to-End Encryption

You are an expert software architect and teacher. I want to understand end-to-end encryption as a practical system design capability. (Signal Protocol, key exchange, ratcheting, and encrypted storage for private communication).

Use the following architectural guide as a learning reference. Avoid one-size-fits-all recommendations. Keep assumptions, costs, and tradeoffs explicit.

---

import { Mermaid, ComponentList, ComponentCard, ApproachList, Approach, Example, Tradeoff } from '@/components/mdx';

## The Problem

Users expect their private messages, files, and data to be protected from everyone — including the service provider. End-to-end encryption (E2EE) ensures that only the communicating parties can read the content; the server handles encrypted blobs it cannot decrypt. Implementing E2EE requires solving key exchange (how do two parties agree on a shared secret over an insecure channel?), forward secrecy (compromising today's key shouldn't reveal past messages), multi-device synchronization (encryption keys across phone, laptop, tablet), and group encryption (efficiently encrypting for N participants). The server must be designed as an untrusted relay.

## Architectural Approaches

<ApproachList>
<Approach
  name="Signal Protocol (Double Ratchet)"
  pros={[
    "Forward secrecy — compromising one key doesn't reveal past messages",
    'Break-in recovery — new keys are generated continuously',
    'Asynchronous key exchange — works even when recipient is offline',
    'Proven security — formally verified and widely audited',
  ]}
  cons={[
    'Complex implementation — multiple layers of key derivation',
    'Key management overhead — per-device, per-conversation key pairs',
    'Multi-device support requires additional protocol extensions',
    'Cannot search encrypted content server-side',
  ]}
>
The gold standard for messaging E2EE, used by WhatsApp, Signal, and Facebook Messenger. Combines the **X3DH** k...

[Full prompt copied to clipboard]