End-to-end encryption, explained: what 'E2EE' actually means, and what it does not

“End-to-end encrypted” is one of the most marketed phrases in consumer technology. It has a real meaning, and it is genuinely important when a service provides it correctly. It is also applied liberally to services that do not quite qualify, and — more commonly — it is believed to mean things it does not.

This article gives you a working definition, explains what the phrase guarantees and what it does not, and shows you how to ask the right questions of any service that claims to offer E2EE for your documents or messages.

The definition

A communication or storage system is end-to-end encrypted if encryption and decryption happen only on the endpoints, using keys that only the endpoints possess. The service in the middle sees ciphertext — a sequence of bytes that, without the key, looks random.

Contrast with ordinary “encrypted in transit” and “encrypted at rest”:

• In transit encryption (TLS) stops network eavesdroppers, but the service decrypts at its end.
• At rest encryption stops someone who steals a disk, but the service holds the key and can decrypt the file on demand.
• End-to-end encryption stops the service itself. The service doesn’t hold a usable decryption key.

The encryption at rest vs in transit article goes deeper on the first two. This one is about the third.

Why it is a strong property

A service that holds your decryption keys can:

• Be compelled by a subpoena, warrant, or national-security letter to hand over your data.
• Be compromised by an attacker who obtains its master keys, exposing every customer’s data.
• Be changed by a future management or owner who decides your data is now a profit center.
• Be affected by a disgruntled or curious insider.

A service that does not hold your decryption keys cannot do any of these things — it cannot turn over plaintext it does not have. That is the entire point.

Signal, WhatsApp, iMessage, ProtonMail, Proton Drive, Tresorit, Cryptomator, and Standard Notes are examples of end-to-end encrypted services for their respective domains (messaging, email, document storage, notes). Dropbox, Google Drive, iCloud Drive (for most content), Gmail, and Outlook.com are not — they use at-rest and in-transit encryption, and hold the keys.

Questions to ask before you trust the claim

Many services call themselves “encrypted” without being end-to-end encrypted, and some call themselves “end-to-end encrypted” in marketing while shipping something weaker. Ask:

1. Where are the keys generated?

On your device is the right answer. If the server generates the keys and sends them to you, the server has, by definition, seen the keys.

2. Can the service reset your password without losing your data?

If yes, the service either holds a copy of your key (or something that can derive it), or the encryption is not actually protecting your data. The real E2EE answer is “if you lose your password, your data is gone” — which is why these services spend a lot of effort on recovery phrases, secondary keys, and trusted contacts.

3. Does the service support “read without decrypting” features like server-side search or thumbnails?

If yes, your content is either being decrypted on the server (not E2EE) or the service is using clever cryptography that keeps the data encrypted. The honest answer is the former in most cases. Read the fine print.

4. Is the cryptographic protocol public?

Reputable E2EE services publish their protocols and often their source code. Signal’s protocol is open and has been widely reviewed; Proton’s technical documents are public; iMessage’s protocol is described in Apple’s Platform Security documents. “Trust us” is not an E2EE claim; it is a marketing claim.

5. What about metadata?

E2EE protects content. Metadata — who you talked to, when, how long, file sizes — is usually not covered. A platform may genuinely not be able to read your messages but may still be able to reconstruct your social graph from their delivery logs. Signal goes to unusual lengths to avoid collecting metadata; most competitors do not.

The E2EE usability tax

End-to-end encryption has real costs, and honest services will tell you about them upfront:

• No password reset. Lose your password and your data is truly gone. This is why recovery phrases, paper backups of keys, and trusted-contact recovery schemes matter. It is the same tradeoff as the FileVault/BitLocker recovery key problem.
• No server-side search. The server can’t search files it can’t read. Clients have to do the searching locally.
• Slower first sync on new devices. Since the new device has to decrypt everything locally rather than rely on a pre-indexed server.
• Broken sharing semantics in rare cases. Sharing a file with someone new means re-encrypting keys, not just flipping a permission bit.

When a service is “better” than E2EE on all these dimensions, it is usually not actually E2E encrypted.

What it all adds up to for documents

For the documents on your computer, E2EE is the right goal for a specific subset: the documents where “the service provider could be compelled or compromised to hand over plaintext” is an unacceptable outcome.

For most people, that subset is not the whole document library — it is the part with legal files, medical records, financial plans, intimate communications, and work-in-progress writing. For everything else, ordinary cloud storage with at-rest and in-transit encryption is perfectly reasonable.

A practical pattern:

1. Ordinary cloud storage (Google Drive, iCloud Drive, OneDrive, Dropbox) for everyday documents.
2. An E2EE overlay for the sensitive subset — either a purpose-built E2EE service (Proton Drive, Tresorit) or a local encryption tool (Cryptomator, VeraCrypt) whose output you drop into ordinary cloud storage.

That gives you the convenience of the big providers and the confidentiality of E2EE, without forcing everything through a service that may have feature gaps your whole life doesn’t deserve.

The next article in this topic, Client-side encryption on top of Dropbox and Drive, walks through the Cryptomator variant step by step.