Caloogy Article
中文

End-to-End Encryption Comparison: WhatsApp, Signal, Telegram, and Self-Hosted Solutions

Date
Oct 30, 2026
Series
Cryptography
Reading
5 min
Topics
E2eeSignal protocolWhatsappTelegram

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:

  1. Layer 1: The Intuition: Sending registered mail vs. sending a safe
  2. Layer 2: Real-World Use: A comparison of various applications
  3. 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:

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
WhatsApp 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:


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):

3.3 Why group chats and multi-party calls are difficult

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)