The one-sentence version
"Encryption" has two completely different meanings: Transport Encryption only protects the segment "from your phone to the server," meaning the server can see the plaintext; End-to-End Encryption (E2EE) can only be decrypted by the two communicating parties, and the server only forwards the ciphertext. Major applications differ significantly in this regard: WhatsApp, Signal, and iMessage are E2EE by default; Telegram's standard chats and all group chats are not end-to-end encrypted—only "Secret Chats" enabled manually are. Furthermore, end-to-end encryption protects the content, but does not protect metadata, such as "who is talking to whom and when."
This article has three layers:
- Layer 1: The Intuition: Sending registered mail vs. sending a safe
- Layer 2: Real-World Use: A comparison of various applications
- Layer 3: Principles and Engineering details: Signal Protocol, identity verification, challenges in group chats and multi-party calls, metadata, and backups
Layer 1: The Intuition
1.1 Two types of "Encryption"
| Analogy | Can the server see the content? | |
|---|---|---|
| Transport Encryption | You hand a letter to a sealed postal van. The van is secure, but the post office opens and sorts it before loading it into another sealed van for delivery. | Yes |
| End-to-End Encryption | You lock a letter inside a safe that only the recipient has the key to. The post office is only responsible for moving the safe. | No |
Many applications claim "our messages are encrypted," which may only refer to the first type.
1.2 Why some applications do not implement end-to-end encryption
Transport encryption makes many features easy to implement:
- All historical messages automatically appear after switching to a new phone (the server has the plaintext);
- Seamless synchronization across web, desktop, and mobile;
- Server-side search, massive group chats, and bots.
With end-to-end encryption, these become difficult because the server cannot see anything.
Layer 2: Real-World Use
| One-on-one Chat | Group Chat | Voice/Video Call | Enabled by Default | Identity Verification Method | |
|---|---|---|---|---|---|
| Signal | E2EE | E2EE | E2EE | Yes | Safety Numbers / QR Code |
| E2EE (Fully default since 2016, using Signal Protocol) | E2EE | E2EE | Yes | Safety Numbers / QR Code; Key Transparency | |
| iMessage | E2EE | E2EE | FaceTime E2EE | Yes | Contact Key Verification |
| Facebook Messenger | E2EE (Default since late 2023) | Rolling out | E2EE | Yes | — |
| Telegram | Standard Chat: Transport Encryption only; Secret Chat: E2EE (must be enabled manually) | Transport Encryption only | One-on-one calls are E2EE | No | Both parties verify a few emojis during the call |
| Zoom | — | Optional E2EE | Optional E2EE | No | — |
A few noteworthy details:
- Telegram Secret Chats use classic Diffie–Hellman (with 2048-bit security primes). The client verifies parameters to prevent man-in-the-middle attacks and periodically renegotiates keys (see Diffie–Hellman and Discrete Logarithms, Forward Secrecy). Secret chats only support one-on-one communication and do not sync across devices.
- Post-Quantum Upgrade: Signal added PQXDH in 2023, and iMessage introduced PQ3 in 2024. Both add a layer of lattice-based KEM on top of existing Elliptic Curve key exchange to defend against "store now, decrypt later" attacks (see Post-Quantum Cryptography).
- Backups are a common vulnerability: While chats are end-to-end encrypted, if cloud backups are not encrypted, the content remains on the server in another form. WhatsApp has provided end-to-end encrypted backups since 2021, and Apple has provided "Advanced Data Protection" since 2022, but both require the user to enable them manually.
Layer 3: Principles and Engineering
3.1 The two parts of the Signal Protocol
| Phase | Algorithm | Problem Solved |
|---|---|---|
| Session Establishment | X3DH (now PQXDH) | Allows starting a secure conversation even when the recipient is offline: the initiator performs several DH operations using a batch of one-time public keys pre-stored by the server. |
| Sending/Receiving Messages | Double Ratchet | Every message uses a new key, providing forward secrecy and post-compromise recovery (see Forward Secrecy). |
The server's role is merely that of a "public key distributor" and a "ciphertext forwarder."
3.2 The Achilles' heel of E2EE: How do you know the recipient's public key is real?
End-to-end encryption relies on one premise: the public key you receive actually belongs to the recipient. If the server (or an attacker who has breached the server) gives you a fake public key, it can decrypt and re-encrypt the message in the middle, acting as an invisible man-in-the-middle.
The solution is out-of-band verification (see Out-of-band Verification):
- Signal, WhatsApp: Scan a QR code in person, or compare safety numbers through another channel;
- Telegram Calls: Both parties read out a few emojis displayed on the screen during the call;
- Key Transparency: WhatsApp and iMessage write public keys to publicly auditable logs, allowing the client to automatically check if the server has "secretly swapped the key" for someone (see Hash Chain Audit Logs, TOFU, and Public Key Pinning).
3.3 Why group chats and multi-party calls are difficult
- Group Chats: For every message sent, it must be encrypted separately for each member, or a group key must be maintained and updated whenever membership changes. As the number of members increases, the overhead and complexity rise sharply. The MLS (RFC 9420) protocol released by IETF in 2023 uses a tree structure to reduce the cost of group key updates to .
- Multi-party Video Calls: These usually pass through a relay server (SFU). In standard WebRTC, each participant establishes an individual encrypted connection with the SFU; therefore, the SFU can decrypt the audio and video, meaning it is no longer end-to-end encrypted. To achieve E2EE, an additional layer of encryption must be added to the media frames (e.g., WebRTC's Encoded Transform / Insertable Streams, or the SFrame standard), allowing the SFU to only forward frames it cannot decrypt.
3.4 Checklist for self-hosted solutions
If you are building your own calling or messaging system, you can check against these questions:
| Question | Description |
|---|---|
| Can the server see the plaintext? | One-on-one WebRTC is E2EE; passing through an SFU is not. |
| Is there forward secrecy? | Real-time calls usually have it; stored content usually does not (see Forward Secrecy). |
| How is the recipient's identity confirmed? | If public keys or certificate fingerprints are passed through your own server, a server breach allows for a man-in-the-middle attack; short codes must be provided for verification. |
| How is stored data encrypted? | Use recipient public keys for envelope encryption (see Envelope Encryption); the server should only store ciphertext. |
| What about metadata? | Who, when, with whom, and for how long—this is usually still exposed to the server. |
3.5 Metadata
End-to-end encryption protects the content. However, metadata—such as "who contacted whom, at what time, and for how long"—often reveals more than the content itself. A former US intelligence official once stated bluntly: "We kill people based on metadata." Signal uses technologies like "sealed sender" to minimize the metadata visible to the server; most other applications still see the complete social graph.
Summary
| Layer | Key points |
|---|---|
| Distinction | Transport Encryption: Server can see; End-to-End Encryption: Server only forwards ciphertext |
| Current State | Signal, WhatsApp, iMessage are E2EE by default; Telegram is not |
| Vulnerabilities | Public key authenticity relies on out-of-band verification or key transparency; cloud backups; metadata |
| Challenges | Group chats (MLS), multi-party calls (SFU requires an additional layer of frame encryption) |