End-to-End Encryption

An encryption model where messages are encrypted on the sender's device and can only be decrypted by the intended recipient, with no intermediate party (including the service provider) able to read them in transit.

End-to-end encryption (E2EE) ensures that a message is readable only by the sender and the intended recipient. It is encrypted on the sender’s device using the recipient’s public key, travels through every hop (the provider, the network, every relay) as ciphertext, and is decrypted only on the recipient’s device with their private key.

No middleman, including the service operating the network, can read the contents.

How it differs from regular TLS

Standard web and email connections use TLS to encrypt data in transit. TLS protects the connection between your device and the server, and between the server and the next hop. But at each server along the way, the data is briefly decrypted and re-encrypted. Anyone running an intermediate server (Gmail, Outlook, the ISP) can read the content while it passes through their infrastructure.

End-to-end encryption closes that gap. The sender encrypts once, for the recipient, and the content stays encrypted across every intermediate hop.

How it works

E2EE relies on asymmetric (public-key) cryptography:

1. Each user has a keypair — a public key they share freely, and a private key they keep secret.
2. Sender encrypts with recipient’s public key. Only the matching private key can decrypt the result.
3. Ciphertext travels through the network. Every server along the way sees only the encrypted blob.
4. Recipient decrypts with their private key. The plaintext appears only on the recipient’s device.

Modern implementations (Signal Protocol, OpenPGP, MLS) layer additional properties on top of this basic model: forward secrecy (compromising one key does not expose past messages), deniability, and group messaging.

Where it is used

• Messaging: Signal, Threema, WhatsApp (since 2016), iMessage between Apple devices
• Email: Proton Mail (between Proton users automatically), Tutanota, and any email encrypted with PGP
• Video calls: Signal, FaceTime, Jitsi (with E2EE enabled)
• File sharing: Proton Drive, Tresorit share links with end-to-end keys embedded in the URL fragment

End-to-end vs zero-access

People often confuse the two, but they describe different things:

• End-to-end encryption protects data in transit between two parties. It is about communication.
• Zero-access encryption protects data at rest on a provider’s server. It is about storage.

A service can be end-to-end encrypted for messages but still store those messages in a form the provider can decrypt later (rare, but possible). A service can be zero-access for stored data but send that data over normal TLS (common for file storage). The strongest services combine both: end-to-end between users, zero-access for anything stored on the provider’s servers.

What E2EE does not do

• Metadata is still visible. Who you talk to, when, how often, and message sizes are often not encrypted. Signal minimizes this; most services do not.
• Endpoint compromise defeats it. If malware runs on your device, it reads plaintext before encryption or after decryption.
• Key trust is the weak point. If an attacker can substitute their own public key for the recipient’s, they can intercept and re-encrypt messages without either party noticing. This is why Signal, WhatsApp, and Proton Mail show “safety numbers” or key fingerprints for manual verification.
• Backups often break E2EE. Cloud backups of encrypted chats (iCloud, Google Drive) may upload plaintext or provider-accessible keys, silently bypassing the encryption guarantee. Check backup settings separately.

Why it matters for Swiss businesses

For communications under nDSG scope (client data, personal information, regulated content), E2EE is the cleanest way to demonstrate that a third party cannot access the content, even by subpoena. Between Proton users, E2EE is automatic. For mixed environments (Proton to Gmail, for example), encryption to external addresses requires either PGP setup on both sides or a password-protected message workflow.