End-to-end encryption works by encrypting data on the sender's device with keys that exist only on the communicating devices, so that the service which stores or relays it holds nothing but ciphertext and cannot read it, and the data is decrypted only on the recipient's device. It differs from ordinary encryption in transit, where the server decrypts and can read everything, by moving the keys out of the provider's reach. Zero-knowledge encryption applies the same principle to stored data: the provider keeps your files or passwords encrypted with keys it never has.
The phrase end-to-end encryption, or E2EE, has become the mark of a trustworthy messenger or storage service, and it is often applied loosely. This guide explains exactly what it means, how it works mechanically including key exchange and forward secrecy, how it differs from encryption in transit and at rest, what zero-knowledge encryption and zero-knowledge architecture add, how to tell whether a service really has it, and what it cannot protect.
What end-to-end encryption means
Any online service has three parties: you, the other party or your future self, and the service in between. Ordinary encryption protects the links between them: your connection to the server is encrypted with TLS, as the HTTPS guide on this site explains, and the server stores data encrypted on disk. At the server, though, the data is decrypted, because the server holds the keys to both links. The provider can read it, scan it, hand it over or lose it in a breach.
End-to-end encryption changes where the keys are. The two ends generate and hold the keys; the server never receives them. Data is encrypted before it leaves your device and stays encrypted until it reaches the other end. The server sees who is talking to whom and how much, and nothing else. A breach of the server yields ciphertext. A legal demand yields ciphertext. An employee who peeks sees ciphertext.
That is the definition, and it is testable: if the provider can read your data under any circumstance, including to reset your password or to show you a preview in a web interface without your key, it is not end to end.
How end-to-end encryption works in messaging
Modern messengers implement E2EE with a protocol pattern that most of them share, built on the asymmetric and symmetric encryption described in the guide on this site.
- Key generation. When you install the app, your device generates a long-term identity key pair and a set of shorter-lived key pairs. Private keys stay on the device. Public keys are uploaded to the server.
- Key agreement. When you message someone for the first time, your app fetches their public keys from the server and runs a key agreement, combining several key pairs so that the result is secret even if some keys are later compromised. Their app performs the matching computation. Both now share a secret the server never saw.
- Message keys and ratcheting. From the shared secret, each app derives a chain of message keys, advancing the chain with every message and mixing in fresh key agreements periodically. Each message is encrypted with a key used once and then deleted.
- Encryption and sending. Each message is encrypted with an authenticated cipher such as AES-GCM or ChaCha20-Poly1305 and sent to the server, which stores it until the recipient is online and then delivers it.
- Decryption. The recipient's app derives the same message key and decrypts. If a key is missing or the message has been tampered with, decryption fails visibly.
- Verification. Each conversation has a safety number or fingerprint derived from both parties' identity keys. Comparing it out of band confirms that the server did not substitute keys, which is the one attack the design cannot rule out without user verification.
Group chats extend the same ideas with per-group keys distributed to members over pairwise encrypted channels.
Forward secrecy and why it matters
Because message keys are used once and then discarded, and because the chain is advanced with new randomness, compromising a device today does not reveal messages from last month, and recording ciphertext today does not become readable if a key leaks later. This is forward secrecy, and it is the main property that distinguishes modern messaging protocols from PGP, which encrypts every message to the same long-lived key, as the PGP guide on this site notes.
End-to-end versus in transit versus at rest
| Layer | What is encrypted | Who holds the keys | Protects against |
|---|---|---|---|
| In transit (TLS) | The connection between you and the server | You and the server | Network eavesdroppers |
| At rest | Data on the server's disks | The server | Stolen disks, some breaches |
| End to end | The data itself, from device to device | Only the endpoints | The provider, server breaches, legal demands to the provider |
Most services have the first two and describe themselves as encrypted. Only the third means the provider cannot read your data. Marketing that says "encrypted" without "end-to-end" almost always means the first two.
Zero-knowledge encryption and architecture
Zero-knowledge encryption is end-to-end encryption applied to data you store rather than send: cloud files, password vaults, notes, backups. Your device encrypts the data with a key derived from your master password or stored in your device's secure hardware, and uploads ciphertext. The provider stores and syncs it but has zero knowledge of the content. When you open the data on another device, you enter the password, the key is derived again, and the data is decrypted locally.
A zero-knowledge architecture is a service designed so that every component operates only on ciphertext: no server-side search of content, no previews generated on the server, no password reset that recovers data, no support staff who can look inside. The trade-offs follow directly. Forgetting the master password means losing the data, unless you stored a recovery key. Features that need to read content, such as server-side search or thumbnail generation, must be done on the device or not at all. The encrypted cloud storage and encrypted notes guides on this site cover services built this way.
How to tell whether a service is really end to end
- The provider states that it cannot read your content and cannot recover it if you lose your password.
- The protocol or design is published, and ideally the client code is open source.
- There is an independent security audit of the implementation.
- Keys are generated on your device and there is a way to verify them, such as a safety number or key fingerprint.
- Web access, if offered, requires your password to decrypt in the browser rather than showing content the server already decrypted.
- E2EE is on by default, or clearly indicated when enabled; optional "secret" modes that are off by default leave most conversations unprotected.
- Backups are encrypted with keys you hold, since an unencrypted backup undoes everything.
What end-to-end encryption does not protect
The ends are the weak points by definition. Malware or spyware on your device reads messages as you do. Someone with your unlocked phone reads them too. Screenshots, forwarding and the other party's choices are outside your control. Metadata, meaning who you talk to, when and how much, is visible to the provider unless it takes specific steps to minimise it, and your identity is usually known to the provider through a phone number or account. Anonymity and metadata protection are separate problems, addressed in the anonymity guides on this site. And an E2EE service that also holds an unencrypted cloud backup of your chats has quietly reintroduced the server as a reader.
What protocol designers and cryptographers say
The account above follows the published protocol designs and their analysis.
The designers of the widely adopted messaging protocol that most E2EE apps use or adapt have documented the key agreement and ratcheting steps described here and the forward secrecy they provide, and the protocol has been formally analysed by academic cryptographers.
Providers of zero-knowledge services document that they cannot reset passwords or recover data, and describe the client-side key derivation that makes this so.
Security researchers evaluating E2EE products emphasise default-on encryption, open protocols, independent audits, key verification and encrypted backups as the criteria that separate genuine end-to-end encryption from marketing claims, and consistently note that device compromise and metadata remain outside its protection.
Check the keys, then trust the service
When a service says end-to-end encrypted, ask where the keys are. If they are on your devices and nowhere else, the provider is out of the picture and the claim is real. Then protect the ends: lock the device, verify safety numbers for conversations that matter, and encrypt or disable backups. The messaging and storage guides on this site apply this to the specific apps you are choosing between.
Frequently asked questions
What does end-to-end encryption mean?
It means data is encrypted on the sender's device and decrypted only on the recipient's device, with the keys held solely by those endpoints. The service that stores or relays the data, and anyone who intercepts it, sees only ciphertext. Not even the provider can read it.
How does end-to-end encryption work in messaging apps?
Each device generates key pairs and publishes public keys through the service. When you message someone, your app uses their public keys to agree a shared secret, derives message keys from it, and encrypts each message before sending. Their app derives the same keys and decrypts. Keys rotate with each message for forward secrecy.
What is the difference between end-to-end encryption and encryption in transit?
Encryption in transit, such as TLS, protects data between your device and the server; the server then decrypts and can read it. End-to-end encryption keeps data encrypted through the server, which never has the keys. Most services have the first; only some have the second.
What is zero-knowledge encryption?
A design in which the provider stores your data encrypted with keys derived from your password or held on your device, so that the provider has zero knowledge of the content. It is end-to-end encryption applied to storage: cloud files, passwords, notes and backups. A zero-knowledge provider cannot reset your password or recover your data.
Does end-to-end encryption make me anonymous?
No. It protects the content of communication. The provider still typically knows who you are, who you communicate with, and when. Anonymity requires separate measures, covered in the anonymity guides, and end-to-end encryption does not protect a compromised device.
Last reviewed and updated on . Plain text version: /encryption/end-to-end-encryption.txt.
