Study guide 129 of 183

End-to-end encryption in messaging

How end-to-end encrypted chat works and what it changes in the design: identity and prekeys, the X3DH key agreement and Double Ratchet, forward secrecy, multi-device support, group messaging with sender keys, encrypted media and backups, key verification, and what the server can and cannot do.

Reading is half of it. See this used in a real interview: walk through Design WhatsApp →

With end-to-end encryption (E2EE), only the sender's and recipients' devices can read a message; the servers that store and relay it see ciphertext. WhatsApp, Signal and iMessage work this way. "Design WhatsApp" often includes a follow-up about encryption, and E2EE changes much more than the transport: search, backups, multi-device, moderation and group messaging all work differently. This guide covers the essentials without the cryptographic proofs.

Encryption in transit is not E2EE

TLS protects data between a device and the server; the server decrypts it. That is necessary but not sufficient: anyone with server access (an insider, an attacker, a legal order) can read messages. E2EE encrypts on the sender's device for the recipient's device keys, and the server never holds the keys. See encryption and key management.

Keys and the key server

Each device generates key pairs locally; private keys never leave it:

A long-term identity key.
A medium-term signed prekey, rotated periodically.
A batch of one-time prekeys, uploaded to the server and consumed one per new conversation.

The server's key directory stores only public keys and hands them out so others can start encrypted sessions even while the recipient is offline.

Starting a session: X3DH

To message someone for the first time, the sender fetches the recipient's identity key, signed prekey and one one-time prekey, and combines several Diffie-Hellman exchanges to derive a shared secret (the Signal protocol's X3DH). The recipient derives the same secret when the first message arrives. No round trip is needed, which matters for asynchronous messaging.

Ongoing messages: the Double Ratchet

After the session starts, every message uses a new key:

A symmetric ratchet derives a fresh key for each message from a chain.
A Diffie-Hellman ratchet mixes in new key exchanges as the conversation goes back and forth.

Results:

Forward secrecy: stealing today's keys does not decrypt past messages.
Post-compromise security: after a compromise, new exchanges heal the session so future messages are safe again.
Out-of-order and missing messages are handled by keeping skipped message keys for a while.

Multi-device

Each device has its own keys. A message to a user is encrypted separately for each of their devices (and for the sender's other devices, so they stay in sync). The server's directory lists a user's devices; adding a device requires linking it from an existing one (for example by scanning a QR code). This multiplies send work by device count, so it shapes the fan-out design. See presence and connection management.

Groups: sender keys

Encrypting every group message separately for every member's every device is expensive for large groups. With sender keys, each member creates a sender key for the group and distributes it to the other members once, through pairwise encrypted sessions. Afterwards, a message is encrypted once with the sender key, and the server fans out the same ciphertext to all members. When membership changes, keys are rotated so removed members cannot read new messages. See group chat fan-out.

Media

Attachments are encrypted on the device with a random key, uploaded as ciphertext to object storage, and the key (with a hash for integrity) is sent inside the encrypted message. The server stores blobs it cannot read; forwarding a file reuses the blob with the same key. See media uploads and processing.

What the server still does

The server routes, stores until delivery, delivers push notifications, manages groups and the key directory, and sees metadata: who talks to whom, when, message sizes, IP addresses. Minimising metadata (sealed sender, short retention) is a separate design goal. See privacy and data deletion.

What E2EE changes in the product

Server-side search of message content is impossible; search runs on the device.
Backups must be encrypted with a key the server does not have (a user password or a hardware-backed key), or they undermine E2EE.
Moderation and spam detection cannot scan content on the server; they rely on metadata, user reports (which include the reported messages) and on-device signals. See trust and safety.
New devices cannot read old history unless it is transferred from an existing device.
Push notifications carry no plaintext; the app decrypts after waking. See push notifications.

Verifying identity

A malicious server could hand out its own public keys and sit in the middle. Users can compare safety numbers (fingerprints of identity keys) or scan QR codes; apps warn when a contact's identity key changes. Key transparency logs (public, append-only directories) make server misbehaviour detectable at scale. See Merkle trees.

Beyond chat

The same ideas apply to encrypted file storage (files encrypted per user or per share with keys wrapped for each recipient) and password managers. Sharing and key recovery become the hard product problems. See Design Dropbox.

In the interview

"Devices generate identity and prekeys and publish only public keys to a key directory; sessions use the Signal protocol (X3DH then Double Ratchet) for forward secrecy; each message is encrypted per recipient device, and groups use sender keys so the server fans out one ciphertext; media is encrypted client-side with keys inside the message. The server stores and routes ciphertext and sees only metadata, so search is on-device, backups are encrypted with a user-held key, and abuse handling relies on reports and metadata." See Design WhatsApp.

Checklist

Keys generated and kept on devices; server holds public keys only.
Asynchronous session setup with prekeys; ratcheting for forward secrecy.
Per-device encryption; device linking for multi-device.
Sender keys for groups, rotated on membership changes.
Client-side encrypted media with keys in messages.
Product consequences: on-device search, encrypted backups, report-based moderation.
Key verification and change warnings.