Messaging apps: Signal and WhatsApp
You send a message to your best friend. A few hundredths of a second later it's on his screen, and on the way it went through at least five computers you've never seen. Yet Signal and WhatsApp both claim that not one of those five read it — not even they themselves. That's a big promise, and it can be kept. This chapter shows with which parts, and where the promise stops.
Words you might need
- End-to-end encryption
- Encrypted from your device all the way to the other person's, and decrypted nowhere in between. The server sees only ciphertext. Often shortened to E2EE.
- Transport encryption
- Encrypted only on the line. The server decrypts, looks, and encrypts again for the next leg. That's what the padlock in your browser does, and it's something else entirely.
- Signal protocol
- The recipe Signal came up with and that WhatsApp uses too. It isn't an app but an agreement about which calculation happens when.
- Prekey
- Half a key exchange that you leave behind at the server in advance, so that someone can reach you while you're asleep.
- Ratchet
- The toothed wheel in a socket wrench, which can only turn one way. Here: the key shifts one tooth along with every message and can never go back.
- Metadata
- Everything around the message: who, to whom, when, how often, how big. Not the contents, but the envelope.
Encrypted is not the same as end-to-end
Almost every app says it encrypts, and almost every app is telling the truth. The question is up to where. With ordinary transport encryption your message goes encrypted to the server, gets decrypted there, sits readable on a disk, and goes encrypted again to your friend. Whoever owns that server reads along: the company, an employee who goes too far, a burglar, a judge with a warrant.
With end-to-end encryption the server doesn't have the key. Not because the company promises not to look at it, but because there's nothing to look at. That difference isn't legal or ethical, it's mathematical, and it holds even if the company changes hands.
| Transport encryption | End-to-end encryption | |
|---|---|---|
| Who has the key? | you, the server, the other person | you and the other person |
| What's on the server? | your message, readable | ciphertext |
| What can the server hand to the police? | the contents | the ciphertext, and that's worthless |
How do you reach someone who's asleep?
chapter 5 ended with a limitation: Diffie–Hellman needs two parties taking part at the same time. You send something, she sends something back, and only then do you have a shared secret. But your friend is asleep at three in the morning, and your message still has to be there when he wakes up.
The solution is called X3DH, from Extended Triple Diffie–Hellman. The idea: you do your half of the exchange in advance, and leave it behind at the server.
- When you install the app, your device makes a little stack of key halves: one fixed one (your identity) and a supply of throwaway ones. The public halves go to the server, the secret ones stay on your device.
- If I want to send you something while you're offline, I fetch such a stack. That's all I need.
- I do the exchange on my own: my secret against your public halves. Out of that comes a shared secret. I encrypt my message and send it on.
- When you wake up, you do the same calculation the other way round with your secret halves. Same secret, message readable. The two of us weren't online at the same time for a single second.
It isn't new maths: it's three or four times the same Diffie–Hellman from that chapter, on an elliptic curve, and the results get stuck together and run through a hash function (chapter 2). What comes out is just an AES key, and from then on you're back at chapter 4.
Signal switched over here to PQXDH in 2023. That's the same construction, but the shared secret is now worked out in two ways at once: with the classical curve X25519 and with CRYSTALS-Kyber, a method that people think a quantum computer won't get through either. Anyone who wants the secret has to break both. Signal announced that on 19 September 2023.
The key changes with every message
One shared secret for your whole friendship would be a bad idea. Whoever ever gets at it reads everything: today's messages and those from three years ago. That's why the Signal protocol throws the key away after every message and works out a new one. That mechanism is called the double ratchet — double, because two of those one-way wheels are turning.
Two toothed wheels turn through each other. The first is a chain of hash functions: from the key of this message you work out the one for the next, and that calculation only goes one way — exactly the property from chapter 2. The second wheel is a fresh Diffie–Hellman: every time an answer comes back, you both send a new public half along and the chain starts over from the beginning.
Consequence 1: whoever cracks your phone today can't read yesterday
Suppose someone gets hold of your device and pulls out the key that's in it at this moment. With that key they can decrypt the next message. Not the previous one, and certainly not last week's: those keys don't exist any more, and calculating back from today's key to that one is exactly reversing the hash function. That's called forward secrecy: the key only ever moves forward, so a break-in today reaches forward but never back. It's the same principle as a ratchet spanner: you can count the teeth forwards, not backwards.
Consequence 2: a few messages later they've lost the key again
Now the other side. Someone has stolen your key and is reading along. As long as you're only sending, that stays the case — they just turn the hash chain forward with you. But the moment your friend answers, a fresh Diffie–Hellman half comes along, and in it is a new secret number the eavesdropper has never seen. From that moment their chain no longer matches and they're out. That's called post-compromise security, or self-healing: the conversation heals on its own, without anyone having to notice or do anything.
This is the difference with the key card from chapter 8.1. There you have one key that stays, and whoever gets hold of it has it for good. Handy for understanding what's going on, useless for a conversation that lasts years.
Are you actually talking to your friend?
Here the hole from chapter 5 comes back. All that maths makes sure that only you and the owner of those public key halves can read along. It doesn't say that owner is your friend. Whoever owns the server could hand you their own key halves instead of your friend's, hold a separate conversation with you and with him, and pass everything on. A man-in-the-middle, and neither of you notices a thing.
That's why you can check it yourself. Out of your public key and your friend's, the apps work out one number together, and that number you can compare. If it matches on both sides, there's nobody in between. It takes ten seconds and almost nobody does it.
| Signal | ||
|---|---|---|
| What's it called? | safety number | security code |
| Where do you find it? | open the conversation, tap the name at the top, choose View Safety Number | open the conversation, tap the name at the top, choose Encryption |
| What do you see? | a QR code and 60 digits in 12 groups of five | a QR code and 60 digits |
| How do you compare? | sitting next to each other: one of you scans the other's QR code. Not next to each other: read the digits out over the phone | the same |
| Afterwards | you can set the contact to Verified; a tick appears in the header of the conversation | a green tick on a successful scan |
Never compare through the app itself. If someone is sitting in between there, they'll simply adjust the digits. Do it side by side with the QR code, or over the phone where you recognise the voice.
Has your safety number suddenly jumped to a different number? Usually it means your friend has a new phone or reinstalled the app — new keys, new number. But it's exactly the same signal a man-in-the-middle would give. Ask him, through a channel other than that chat.
What the app maker can still see
Not the contents. The envelope, yes, and that's more than you'd think. Who with whom, at what time, how often, how long a conversation lasted, from which IP address, with which device. You don't have to read a single message to know that someone called an on-call doctor for half an hour at 02:14, and the next day spoke three times to his best friend. The contents are secret; the story isn't.
On this point Signal and WhatsApp really do differ, and the difference isn't in the encryption — that's the same protocol in both. It's in what the company keeps.
| Signal | ||
|---|---|---|
| What have they handed to a judge before? | the date the account was created and the date of the last connection. They don't have more. | name, service start date, last seen, IP address, device type, email address, your ‘about’ text, profile photo, groups and contacts — according to their own guidelines for governments. |
| Who talks to whom? | Signal hides that with sealed sender: the sender sits inside the encrypted envelope, the server sees only the recipient. | the server sees which number writes to which number, when and for how long. |
| Your address book | Signal keeps no contact list, group names or profile names on the server; they're stored encrypted. | is part of the data the company holds. |
Signal is a non-profit that lives on donations, WhatsApp belongs to a company that lives on advertising. That explains the difference better than any technical argument: keeping metadata costs money and only pays off if you do something with it.
The back door you open yourself: the backup
You can do everything right and still give it all away. Put your chats in an ordinary cloud backup and there they sit, readable. Not because the encryption failed, but because you yourself put a copy next to it that isn't covered by it. Whoever can get at that cloud has your whole conversation history, and the finest ratchet in the world does nothing about that.
WhatsApp calls the encrypted backup, in its own announcement, an extra, optional layer that you switch on yourself. You'll find it under Settings › Chats › Chat backup › End-to-end encrypted backup. There you choose yourself what you lock it with: a passkey (your fingerprint or face), a password, or a 64-character key that you copy out and keep. Go and check it on your own device — it's the one setting in this chapter you can change today.
If you choose the password, the real key ends up in a secured vault at WhatsApp, which only releases it once the password is right and which counts the number of attempts. If you choose the 64 characters, the key exists only on paper at your place. The second is safer and less forgiving: lose it and your backup is gone, and nobody can get it back. That isn't bad service, that's what the word end-to-end means.
Signal does nothing with the cloud by default. If you do want a backup, you get a 64-character recovery key that's made on your own device and never goes to the server — the same principle, the same responsibility.
And the simplest leak of all: the other person's screen. A screenshot, someone looking over your shoulder on the bus, or a phone lying on the table without a code. No protocol protects against a message simply being read by someone who's allowed to be there. What that means in practice for your device itself is in chapter 7.6.
This is maths: proving a conversation is sound
The ratchet is one long chain: k1 = H(k0), k2 = H(k1), and so on, with H a hash function. That the chain can only go one way isn't a design choice by Signal but a property of H. All the promises above — forward secrecy, self-healing — are consequences you derive from that one property.
Derivations like that are too complicated to trust by hand, because a protocol has dozens of messages that can arrive in any order, disappear or be repeated. That's why there's a field that proves protocols instead of testing them: you write the protocol down as a mathematical object, you write down what an attacker is allowed to do, and you derive that they don't win. For the Signal protocol, Katriel Cohn-Gordon, Cas Cremers, Benjamin Dowling, Luke Garratt and Douglas Stebila did that in 2017, in a paper called A Formal Security Analysis of the Signal Messaging Protocol.
That field is called formal verification, and it sits on the border between logic and computer science. It's the only area in security where you don't have to hope: either you have a proof, or you don't.