End-to-end encryption for system design interviews

How it works

Start with the trust boundary. For an encrypted chat, phones and computers are trusted endpoints; routing servers, queues, databases, and object storage are not trusted with plaintext. TLS still protects client-server connections, but E2EE keeps message contents encrypted even after TLS terminates at the server.

Each device generates cryptographic keys locally and publishes public key material through a directory. Senders must authenticate that material: otherwise, a malicious directory could substitute an attacker’s keys. Depending on the protocol, signed prekeys, user-verifiable fingerprints, device-linking approval, and key transparency help establish or check trust.

Use an established protocol rather than designing cryptography during the interview. For asynchronous chat, published prekeys let Alice establish a session while Bob is offline. The client then uses authenticated encryption to protect message contents and detect tampering; the server stores the encrypted envelope until Bob reconnects.

A ratcheting messaging protocol evolves keys over time. With secure deletion, forward secrecy limits exposure of past messages if current keys are stolen; suitable protocols can also recover security after a temporary compromise ends and fresh secret material enters the session. These properties are protocol-dependent, not automatic consequences of E2EE.

Treat devices and groups as explicit key-management problems. A user with a phone and laptop has multiple recipient endpoints, and a new device needs an authorized enrollment flow. Group protocols must update key state when membership changes so removed members cannot decrypt future messages; they cannot make members forget content already received.

Encrypt attachments on the client with a fresh content key, upload ciphertext to object storage, and deliver the key inside an encrypted message. Define backups separately: a backup decryptable by the service weakens the privacy boundary for that copy, while an independently encrypted backup requires a recovery secret or trusted-device transfer.

A worked example

Sharing an encrypted attachment across six devices

A private chat has three members, each with two enrolled devices. Alice’s phone encrypts a 12 MB attachment once using a fresh random content key and uploads the ciphertext to object storage. It sends the object reference and content key through the chat’s established encrypted sessions to the five other devices, including Alice’s laptop. The backend stores one encrypted attachment rather than five full copies, plus small encrypted delivery envelopes. A disconnected device retrieves its envelope later and decrypts locally. If one member leaves, the group updates its key state for future messages. That member may still retain the old attachment and its key; deleting a server object or revoking access cannot erase an already downloaded copy.

Trade-offs to say out loud

Content privacy versus server-side features: Ordinary server-side search, previews, transcription, and content moderation cannot operate on plaintext the server does not possess, so those features need client-side execution or an explicitly different trust model.
Recovery versus exclusive key ownership: If every authorized device and recovery secret is lost, the service cannot recover encrypted history without a recovery mechanism that changes who can obtain the keys.
Multi-device convenience versus protocol complexity: Device enrollment, offline delivery, key changes, and history transfer add security-sensitive state that must remain correct across retries and partial failures.
Group efficiency versus membership-management cost: Pairwise delivery can multiply encryption work, while group-key protocols improve efficiency but require careful membership updates and synchronization.
Content secrecy versus metadata exposure: E2EE alone does not hide routing identifiers, message timing, sizes, IP addresses, or all group-membership information.
Protected storage versus vulnerable endpoints: E2EE limits what compromised servers can read, but malware, unsafe logs, notification previews, or an authorized recipient can still expose plaintext.

When to reach for it

The requirements explicitly say the service operator must not be able to read private messages or stored files.
You are designing private chat with offline recipients, multiple devices, group membership changes, and encrypted attachments.
A file-sync or private-backup product must protect content even if its storage service is compromised.
The interviewer asks how privacy requirements affect search, moderation, recovery, or server-side media processing.

How to bring it up in the interview

State the threat model first: identify the trusted endpoints, whether the server may be malicious, and which metadata remains visible.
Separate TLS, encryption at rest, and E2EE; explain exactly where plaintext exists and who controls decryption keys.
Walk through one offline send, then a new-device enrollment and a lost-device recovery; interviewers often probe these transitions rather than the encryption algorithm.
Name an established protocol appropriate to the product, then discuss identity verification, forward secrecy, and group changes without inventing a custom protocol.
Call out feature consequences early: explain where search and media processing run, what abuse reporting reveals, and why revocation cannot erase copies already decrypted.

Common mistakes

Calling HTTPS or server-managed disk encryption end-to-end encryption even though the backend can read plaintext.
Assuming public keys fetched from the server are authentic without discussing key substitution or device verification.
Promising password-reset recovery of all history without identifying the separate mechanism that preserves or restores decryption keys.
Claiming E2EE automatically provides forward secrecy, hides metadata, or protects a compromised recipient device.
Adding server-side content indexing, thumbnail generation, or plaintext push notifications without acknowledging that they cross the stated privacy boundary.

Where it comes up

Interview questions where end-to-end encryption is part of a strong answer, and why.

Questions people ask

What is the difference between end-to-end encryption and TLS?

TLS protects a connection between two endpoints, often a client and a server, so that server can usually read the application data. E2EE encrypts content between the intended user devices, leaving intermediary servers without the content keys. Most E2EE applications still use TLS.

Can end-to-end encrypted messages be recovered after losing a phone?

Only if another authorized device or a previously configured recovery mechanism retains access to the necessary keys or encrypted history. Options include trusted-device transfer and backups protected by a separate recovery secret. Resetting an account password alone does not recreate lost encryption keys.

Can a server search or moderate end-to-end encrypted messages?

A server cannot run ordinary plaintext search or content inspection over ciphertext it cannot decrypt. Applications can use local search and user-initiated reports that deliberately disclose selected content. Specialized encrypted-search techniques have their own leakage and functionality limits and are not a drop-in replacement for a normal search index.