What end-to-end encryption protects — and what it misses — is one of the most important distinctions in practical security. This is a technical breakdown.
The Precise Definition
End-to-end encryption (E2EE) means a message is encrypted on the sender's device, travels encrypted through all intermediaries, and is decrypted only on the recipient's device. No server in the path — not the service provider's infrastructure, not your ISP — can read the content.
This is genuinely powerful. Even if Signal's servers are compromised, even if a government serves a lawful demand, even if your traffic is intercepted at a coffee shop — the message content is unreadable to anyone except the intended recipient.
What it does not mean: using an E2EE app makes you private. These are different claims with a significant gap between them.
How It Actually Works: The Signal Protocol
Key Exchange (X3DH)
Before two parties can exchange encrypted messages, they need to establish a shared secret without transmitting it. The Signal Protocol uses X3DH (Extended Triple Diffie-Hellman).
Each user generates several key pairs at registration:
# Each user generates at registration:
IK = Identity Key (long-term, never changes)
SPK = Signed PreKey (rotated periodically, signed by IK)
OPK = One-Time PreKey (consumed once per session, then discarded)
# The server holds public keys only.
# Private keys never leave your device.
When Alice wants to message Bob, she fetches Bob's public keys from the server and performs a series of Diffie-Hellman operations combining her private keys with his public keys. This produces a shared secret that Bob can derive independently — but that no third party who observed the exchange can compute.
The Double Ratchet: Forward Secrecy
Forward secrecy means compromising today's keys doesn't decrypt past messages. Signal achieves this by generating a new encryption key for every single message:
# Each message advances the ratchet
message_key_1 = KDF(chain_key_0)
message_key_2 = KDF(chain_key_1)
message_key_3 = KDF(chain_key_2)
# Each key is used once, then deleted.
# Compromise of message_key_3 reveals nothing
# about message_key_1 or message_key_2.
An attacker who stores your encrypted messages today cannot decrypt them even if they obtain your private key in the future — the keys that decrypted those messages have already been deleted.
Group Messaging: MLS (RFC 9420)
The Double Ratchet scales to two-party conversations. Group messaging is harder. Traditional approaches encrypt to each member individually — sender work scales linearly with group size.
RFC 9420, the Messaging Layer Security (MLS) protocol, solves this with a binary tree key structure:
# MLS tree structure — 4-member group
root_secret
/ \
left_secret right_secret
/ \ / \
Alice Bob Carol Dave
# Adding Eve: only the path from Eve's leaf to root updates.
# Everyone derives the new root from their existing subtree secret.
# O(log n) operations instead of O(n).
MLS also provides post-compromise security: if a member's device is compromised, they can be healed back to security through key rotation — the attacker cannot read future messages once the member rotates keys.
What E2EE Protects
✅ Server compromise — An attacker who breaches the service provider obtains ciphertext they cannot decrypt.
✅ Network interception — Traffic captured in transit is unreadable without the recipient's private key.
✅ Service provider access — The provider cannot read message content even under legal compulsion. There is nothing readable to hand over.
✅ Historical messages — With forward secrecy, past messages remain encrypted even after future key compromise.
What E2EE Does Not Protect
❌ Metadata — Who you communicate with, when, how often, and from where are visible to the service provider and the network. E2EE encrypts the payload, not the envelope. [General Michael Hayden, former NSA/CIA director, was not exaggerating when he said "we kill people based on metadata."]
❌ Endpoint compromise — If an attacker controls either device — malware, physical access, compromised OS — they read plaintext before encryption or after decryption. E2EE only protects data in transit.
❌ Key distribution attacks — A service provider who controls the key directory can substitute an attacker's key for your contact's. You would encrypt to the attacker thinking you're encrypting to your contact. This is why Signal has "safety numbers" and PGP has key fingerprints. In practice, almost no users verify them.
❌ Identity linkage — If your account requires a phone number, your encrypted communications are linked to your carrier identity. E2EE says nothing about who you are, only that what you said is private.
⚠️ Stored messages — E2EE applies to transmission. If messages are backed up to cloud storage without E2EE (pre-2022 iCloud backups of iMessage), the backup is the vulnerability.
The Key Distribution Problem
The most underappreciated weakness in E2EE deployments: you have to actually encrypt to the right key. How does your app know the key it fetched for alice@example.com belongs to Alice?
In practice, most users trust the key server. Signal's server tells Bob's client what your key is. If Signal's server were compromised or malicious, it could substitute an attacker's key — Bob's client would silently encrypt to the attacker.
The cryptographic solution is out-of-band key verification — comparing fingerprints in person or over a phone call. Signal calls these "safety numbers." PGP calls them key fingerprints. Almost no users do this.
This is not theoretical. Law enforcement and intelligence agencies have legal mechanisms to compel service providers to serve modified key material to specific targets. A well-designed E2EE system makes this detectable — key changes trigger alerts — but only if the user notices.
Zero-Knowledge Architecture Goes Further
E2EE protects messages in transit. Zero-knowledge architecture extends protection to stored data: your messages, email, and files are encrypted before leaving your device, using keys derived from your passphrase that the server never sees.
The difference matters: an E2EE app that stores encrypted history on its servers has protected messages in transit, but the server holds ciphertext it can hand to a third party. A zero-knowledge system means the server has ciphertext and no ability to derive the keys — even a lawful demand for the encrypted data produces data that cannot be decrypted without the user's passphrase.
The Practical Checklist
When evaluating a "secure" messaging or email product, the right questions are:
- Is encryption on by default? Opt-in encryption (Telegram's Secret Chats) is not a privacy feature — it's a disclaimer.
- Who controls the key directory? Can the server substitute keys without detection?
- Is key verification available and surfaced to users?
- What metadata does the provider collect? Who-to-whom, when, and how often are often more revealing than content.
- Does it require a phone number? A phone number is a carrier-issued identifier that links your identity to billing records.
- Is stored data zero-knowledge, or just transit-encrypted?
E2EE is necessary. It is not sufficient. The gap between "encrypted in transit" and "actually private" is where most practical attacks live.
Haven implements end-to-end encryption for chat (MLS/RFC 9420) and zero-knowledge encryption for stored email (client-side PGP). No phone number required. havenmessenger.com
Top comments (0)