"Protected with end-to-end encryption" appears in every messaging app's marketing, yet few technical phrases get used so loosely. E2EE has a precise definition with radical consequences: even the company running the service cannot read your messages. This article explains what makes it possible, why it differs from the HTTPS you use on every site, and — just as important — which threats remain outside its reach.
The fundamental distinction: transport vs content
When you browse over HTTPS, your connection is encrypted... up to the server. The provider sees everything in cleartext inside its infrastructure: can read it, index it, hand it over on legal request or suffer a massive leak. That's encryption in transit: protects against network third parties, not against whoever operates the service.
E2EE adds the missing piece: decryption keys exist only on participants' devices. The server acts as a blind courier — forwarding illegible packages without being able to open them. If an attacker fully compromises the server, they get metadata (who talks to whom, when, how much) but no content.
The mental litmus test: could the company hand over your history if ordered? With genuine E2EE, physically no — it doesn't hold the keys.
The underlying magic: Diffie-Hellman
How do two strangers agree on a secret over a channel watched by everyone? The Diffie-Hellman protocol (1976) solves exactly that with modular arithmetic:
- Alice picks secret
a, publishesA = g^a mod p. - Bob picks secret
b, publishesB = g^b mod p. - Both compute the same shared secret:
A^b = B^a = g^(ab) mod p.
A spy seeing g, p, A and B must solve discrete logarithm to get the secret — computationally infeasible with modern parameters. Elliptic-curve variants (ECDH/X25519) do the same with tiny keys and huge speed; it's the primitive behind today's whole ecosystem.
Pure DH has a nuance: without authentication, an intermediary can mount two separate tunnels (man-in-the-middle). Real systems therefore authenticate public keys — via identities registered server-side, pre-shared secrets or manual fingerprint verification (the QR code you scan when verifying a contact).
Forward secrecy: burning old keys
The property separating serious designs from basic ones: forward secrecy. If someone's long-term private key leaks tomorrow, can past conversations captured today be decrypted?
Naive schemes: yes — disaster. Modern protocols derive ephemeral session keys destroyed after use. Signal Protocol's Double Ratchet (used by WhatsApp, Signal and others) goes further: every message advances a cryptographic "ratchet" — new key derived from the previous one, previous deleted. Compromising one message reveals neither the next nor the previous. Device changes or reconnections additionally trigger fresh DH agreement ("symmetric ratchet + DH"), shielding even against prolonged partial compromise.
What E2EE does NOT protect
This is where marketing falls short. E2EE protects content in transit and at rest on servers. Still exposed:
The endpoints: if they steal your unlocked phone or install spyware, they read your screen — encryption already happened or hasn't yet. The endpoint is always the weakest link.
Unencrypted local copies: many clients store history in plaintext on-device. iCloud/Google backups without advanced encryption enabled = your chats readable by the cloud provider.
Metadata: who communicates with whom, frequency, timing, volume. For many analyses metadata says as much as content — and genuine E2EE doesn't hide it from the operator.
Screenshots and photos: nothing stops photographing the chat. Technical confidentiality doesn't enforce social discretion.
Backups in the service's own cloud: WhatsApp encrypts messages E2EE but its historical Google Drive/iCloud backups were readable unless you enabled backup encryption. Configuration, not technology.
Verify instead of blindly trusting
Two habits raise your real guarantee:
- Verify contacts: nearly all apps show comparable safety numbers/QR codes. Close the residual MITM gap.
- Distrust optional-by-default E2EE: if a platform offers it only for certain chats or buried in settings, their business model probably depends on reading the rest. Serious E2EE is universal by default (Signal) or explicitly configurable (WhatsApp backups).
And to touch the primitives with your own hands: our AES-256-GCM encryptor implements in-browser the symmetric cipher traveling inside these systems — experiment with salt, IV and authentication without installing anything. The TLS handshake, by the way, uses the very same Diffie-Hellman you just read: only who ends up holding the keys changes.
FAQ
Is Telegram E2EE? Only its optional "secret chats", one-to-one. Normal Telegram chats are cloud-encrypted: the server has access. Contrast with Signal or WhatsApp where E2EE covers all chats by default.
Can email be E2EE? Yes, via PGP or modern S/MIME — though historical friction limited mass adoption. Services like ProtonMail implement E2EE between users of the same platform.
If it's so good, why do criminals using it get caught? Because almost no attack breaks cryptography: wins come from endpoints (compromised devices, malware), metadata, human error or suspects failing to verify contacts. The encryption holds; the surrounding systems don't.
Experiment with real AES-256-GCM in your browser using our text encryptor, free and no sign-up.