End-to-end encryption: how it really works (and why marketing abuses the term)

The term "end-to-end encryption" (E2E) is now displayed by almost every cloud service. The problem: the technical definition of the term is precise, and many products use it loosely to describe simple "at rest" encryption.

Encryption at rest vs. end-to-end encryption

Encryption at rest means your files are encrypted on the provider's disks. That's a useful protection against physical theft of hard drives, but it changes nothing about the fact that the provider itself holds the decryption key: it can read your files at any time, and must hand them over in clear text if ordered to by a court.

End-to-end encryption moves the encryption step before the data is sent: the file is encrypted in your browser or device, with a key only you possess. The server only ever receives, stores and transmits already-encrypted content. This is what's called a zero-knowledge architecture: the provider has no technical way to know the content.

How to verify a service is really E2E

• Does encryption happen before upload, on the client side (browser or app)?
• Is the decryption key derived from your password, or from a secret only you hold?
• Can the provider reset your password without losing your data? If so, that's a red flag: it means they hold a copy of the keys.
• Is the client-side encryption code documented or auditable?

At May·Secret, every file is encrypted in the browser with XChaCha20-Poly1305 (via libsodium), before it even reaches our infrastructure. Our security page details the full cryptographic scheme, step by step.

The trade-off: losing your password is irreversible

A genuine zero-knowledge service can't offer classic password recovery, since that would require keeping access to the data in clear text. It's a deliberate trade-off between absolute confidentiality and convenience — as long as you know about it and keep your password in a dedicated password manager.