What is end-to-end encryption?

End-to-end encryption (E2EE) means a message is encrypted on the sender's device and can be decrypted only on the recipient's, so nobody in between can read it, including the service that carries it. The keys that matter exist only at the two ends. That differs from "encrypted in transit", where the service decrypts the message on arrival and could read or change it, and from "encrypted at rest", where the service holds the key to the stored copy. If a company can read your messages whenever it chooses, the system isn't end-to-end encrypted, whatever it says on the box.

Three kinds of "encrypted"

Ordinary web browsing, ordinary email (is email encrypted?) and most cloud storage use the first two. Messaging apps that advertise E2EE for every chat, such as Signal and, since 2016, WhatsApp (which uses the Signal protocol), use the third. In every case, ask what exactly is protected, and from whom.

How it works

Each person has a pair of keys, a public one that can be shared and a private one that never leaves the device. To message someone, the sender's app uses the recipient's public key to derive a key for that conversation. A modern protocol builds a shared secret from both parties' keys with a Diffie-Hellman exchange instead (see Diffie-Hellman). The app then encrypts each message with a fast cipher such as AES or ChaCha20, with authentication, so any change is detected (authenticated encryption). The server relays blobs it can't open. Signal's design goes further. It changes the key with every message (the "double ratchet"), so stealing a key today doesn't unlock yesterday's or tomorrow's messages, and since 2023 it also mixes in a post-quantum key exchange.

The hard part is knowing whose key it is

E2EE has a weak point, because the server usually delivers the public keys too. A dishonest or hacked server could hand you its own key in place of your friend's, decrypt each message, read it and re-encrypt it for your friend. That's a man-in-the-middle attack, and strong encryption doesn't prevent it by itself. Good apps let you check. Signal shows a safety number for each conversation (also as a QR code), a code derived from both people's keys. Compare it in person, or over a channel the server doesn't control, and if it matches, nobody is in the middle. If it later changes, the app warns you, which can mean a new phone or a new attacker. Most people never check, so the protection against this attack is weaker in practice than on paper.

What E2EE doesn't hide

• Metadata. Who talks to whom, when, how often and from where is usually visible to the service even when the contents aren't. Some apps work to reduce this, and many don't.
• The endpoints. Malware on your phone, a person looking over your shoulder or a screenshot defeats it. So does the other person, who can copy, forward or photograph what you send.
• Backups. Messages backed up to a cloud service with a key the provider holds are no longer protected end to end, unless the backup is also encrypted with a key only you have. Check that setting.
• Weak choices around it. A lock-screen preview, a shared computer or an unsafe backup undoes what the cryptography does.

E2EE on the web, and where cipher.ink sits

A web page that encrypts in your browser can be end to end in the narrow sense, since the server stores only ciphertext. cipher.ink is built this way, so the server never receives the text, the file names, the passphrase or a link key (client-side encryption). It has a weakness that apps with a downloaded, signed program don't: the site delivers the code that does the encrypting every time you visit. A site that was hacked, or compelled to, could serve changed code that leaks the plaintext before it's encrypted. That's the standing limitation of web-based encryption, and the security page states it along with the other known edges. The practical difference from a messenger is that cipher.ink has no accounts and no contact list, so there's no long-term identity key to verify. A passphrase or a link key protects the secret, and you hand it to the other person yourself, by a route of your own choosing.

That makes it suitable for sending a one-off secret to someone, such as a password, and unsuited to a long conversation, where an app with verified keys and forward secrecy does better.

A practical checklist

• Ask what's encrypted, from whom, and who holds the keys. Marketing labels about the "grade" of the security mean nothing.
• For anything sensitive, use an app that's end-to-end encrypted by default and open about its design.
• Verify the safety number with the people who matter, once, in person.
• Turn on disappearing messages for sensitive chats, knowing they can't stop the other person from keeping a copy (what self-destructing messages can and cannot promise).
• Protect the device with a screen lock, updates and a trusted source for apps.

Common questions