What the ends are
A message passes through several stops: your phone, your Wi-Fi or mobile network, the internet, the provider's servers, perhaps a backup, the network on the other side and the recipient's phone. End-to-end encryption means the content is encrypted on the first stop and decrypted only on the last. Everything in between, including the provider, handles ciphertext it cannot open.
NIST's glossary, citing its SP 800-12, describes end-to-end encryption as communications encryption in which data is encrypted while passing through a network, and adds a qualifier that matters for everything below: "routing information remains visible." The content is hidden. The envelope is not.
How it differs from HTTPS
Almost every website and app already encrypts traffic with TLS, the protocol behind HTTPS. MDN describes TLS as a protocol that lets a client communicate securely with a server across an untrusted network: the data is encrypted in transit between the two. The HTTP vs HTTPS guide covers that part. The key word is server. With TLS alone, the server decrypts the message when it arrives, so the provider can read it, store it, scan it or hand it over.
Encryption at rest adds another layer on the provider's disks, but if the provider holds the key, it can still decrypt. End-to-end encryption removes the provider from the list of readers.
| How the service handles content | Network can read | Provider can read | Backup readable by provider | Sender and recipient |
|---|---|---|---|---|
| No encryption | Yes | Yes | Yes | Yes |
| Encryption in transit (TLS) | No | Yes | Yes | Yes |
| In transit and at rest, provider holds keys | No | Yes, with the keys | Yes, with the keys | Yes |
| End-to-end encryption | No | No | Only if the backup is end-to-end too | Yes |
The last column never changes: the two ends can always read, which is the point. What changes is everyone in between.
How the keys work
Each device creates a key pair. The public half goes to the server so others can find it; the private half never leaves the device. When you start a chat, your app fetches the other person's public key and the two devices agree on a shared secret that the server cannot compute. The Signal protocol's X3DH specification describes exactly this: it "establishes a shared secret key between two parties who mutually authenticate each other based on public keys", while the server only stores and hands out the published keys and holds messages until the recipient fetches them.
Good protocols keep changing the key. Signal's Double Ratchet derives new keys for every message so that earlier keys cannot be calculated from later ones. Its documentation says this gives some protection to earlier and later messages if a party's keys are compromised. It is a property of the protocol, not something you switch on.
The same idea, at a much smaller scale, is behind the text encryption tool: it encrypts a message with AES-256-GCM in your browser using a password, so whatever channel carries the ciphertext cannot read it. The difference is the key exchange. You have to get the password to the other person by another route, which is the problem public keys solve. The hashing vs encryption vs encoding guide explains where each technique fits.
What it does not protect
| Item | With end-to-end encryption |
|---|---|
| Message text, photos, files | Protected from the service and the network |
| Who talks to whom, and when | Not protected; routing data stays visible |
| A phone that is unlocked or infected | Not protected; the endpoint sees plaintext |
| A cloud backup of the chat | Only if the backup is end-to-end encrypted |
| The person you are talking to | Not protected; they can copy what they read |
| A fake contact or swapped key | Only if you verify the safety code or fingerprint |
- Metadata. The provider has to route messages, so it knows the accounts involved and the timing. NIST's definition says as much.
- The devices. Decryption happens on the phone, so anything that can read the phone's screen or memory reads the message. The X3DH specification notes that compromise of a party's identity private key allows impersonation of that party to others.
- Backups. A chat app can be end-to-end encrypted while its cloud backup is not. Apple documents that, under standard data protection, iCloud Backup is not end-to-end encrypted, and that Messages in iCloud is end-to-end encrypted only when iCloud Backup is off, because the backup includes a copy of the Messages key. With Advanced Data Protection on, the backup is end-to-end encrypted too.
- Services that cannot do it. Apple also notes that Mail, Contacts and Calendars stay encrypted with keys Apple holds even under Advanced Data Protection, because email and the CalDAV and CardDAV standards have to interoperate with other systems.
- The other person. Encryption ends at their screen. They can forward, copy or photograph what they read.
Checking you are talking to the right key
The server hands out public keys, so a server that wanted to listen in could hand you its own key instead of your contact's. The defense is verification. The X3DH specification says the parties may compare public key fingerprints manually or by scanning a QR code, and that without it they "receive no cryptographic guarantee" about who is on the other end. Messengers show this as a safety number or security code in the contact's settings. Compare it once in person or over a call, and again if the app warns that it changed.
The same idea applies to files: comparing a hash published by the sender with the hash of what you received shows whether anything changed in between. The hash generator computes SHA-256 of a file in your browser and compares it with an expected value.
Settings that undo it
CISA's mobile guidance from December 2024 puts it first in its list: "Use only end-to-end encrypted communications." It also states plainly that SMS messages are not encrypted, and that someone with access to a telecom provider's network can read intercepted messages. That makes fallbacks the weak point:
- Turn off sending as SMS when the encrypted service is unavailable. CISA lists this setting for iPhone messaging.
- Use RCS chats only when end-to-end encryption is shown as active, which CISA notes is the case when all participants use Google Messages.
- Do not use SMS for sign-in codes. CISA recommends moving away from SMS as a second factor, and removing the SMS option after enrolling a stronger one.
- Check that cloud backups of your chats are end-to-end encrypted, or turn them off.
Checklist
- Does the service state that content is end-to-end encrypted by default, not just "encrypted"?
- Is the backup end-to-end encrypted as well?
- Have you compared the safety number with the contacts that matter?
- Is SMS fallback off?
- Is the phone itself locked and up to date? End-to-end encryption protects the path, not the endpoints.
Frequently asked questions
What does end-to-end encryption mean?
The message is encrypted on the sender's device and decrypted only on the recipient's device. Servers in between store and forward it but hold no key that opens it. That is the difference from ordinary HTTPS, where the connection is encrypted but the service itself reads the content.
Is HTTPS end-to-end encryption?
No. TLS, the protocol behind HTTPS, encrypts data between a client and a server. The server decrypts it on arrival, so the company running the server can read, store and scan it. End-to-end encryption is a layer on top that keeps the server from reading the content.
Can the provider still see anything?
Yes. NIST's definition notes that routing information remains visible. The service has to know where each message goes, so it generally knows which accounts exchange messages and when, even when it cannot read them.
Are my chat backups end-to-end encrypted?
Not necessarily. Apple, for example, documents that under its standard data protection iCloud Backup is not end-to-end encrypted and that a backup includes a copy of the Messages in iCloud key. Turning on its Advanced Data Protection changes that. Check the backup setting of every app you rely on.
What is a safety number or key fingerprint?
A short code derived from the public keys of both people in a conversation. Comparing it in person or by scanning a QR code proves there is no impostor key in the middle. The Signal X3DH specification states that without such authentication the parties receive no cryptographic guarantee as to who they are talking to.
Sources
- NIST CSRC Glossary: end-to-end encryption, from NIST SP 800-12 Rev. 1 (data encrypted while passing through a network, routing information remains visible)
- MDN Web Docs: Transport Layer Security (TLS lets a client communicate securely with a server; data encrypted in transit between client and server)
- Signal: The X3DH Key Agreement Protocol (shared secret key from public keys, the server stores messages and prekey bundles, fingerprint comparison or QR code, no guarantee without authentication, a malicious server can refuse delivery, identity key compromise allows impersonation)
- Signal: Specifications overview (Double Ratchet derives new keys for every message so earlier keys cannot be calculated from later ones)
- Apple Support: iCloud data security overview (standard data protection vs Advanced Data Protection, iCloud Backup and the Messages key, Mail, Contacts and Calendars not end-to-end encrypted)
- CISA: Mobile Communications Best Practice Guidance, December 18, 2024 (use only end-to-end encrypted communications, SMS messages are not encrypted, stop SMS fallback, RCS only with end-to-end encryption)