Symmetric encryption

One key between two identical, mirrored padlocks that both open towards it.

Julius Caesar wrote his letters to his generals in secret writing: every letter shifted a few places forward in the alphabet. A becomes D, B becomes E. Whoever knew how many places could read it. Whoever didn't, saw nonsense. That "how many places" is the key — and two thousand years later, that idea is still the basis of how your messages get secured.

Words you might need

Key: The secret you need to encrypt and decrypt. For Caesar, a number from 1 to 25. For modern systems, a string of 256 random bits. Whoever has the key can read it. Whoever doesn't, can't.
Symmetric: The same key locks and unlocks. Like the key to your bike lock: one key, and you have to share it with anyone allowed to open the lock.
Plaintext and ciphertext: Plaintext is your ordinary message. Ciphertext is what comes out after encrypting it: just noise to anyone without the key.
AES: The secret-writing system almost everything uses today: your wifi, your messages, your banking app. The world standard since 2001, and in all those years no one has found a hole in it. It comes in three sizes — AES128, AES192 and AES256 — and that number is the length of the key in bits. The demo below uses AES256.

The same key, both ways round

This is the heart of this chapter. Encrypting and decrypting use the same key. In formulas:

ciphertext = AES(key, plaintext)

plaintext = AES⁻¹(key, ciphertext)

Top line: message in, ciphertext out. Bottom line: exactly the other way round — AES⁻¹ is the way back, the way ÷ 3 is the way back from × 3. But look at what appears in both lines: key. The same word, the same value. One key that locks and unlocks, like the key to your bike lock.

You'll see that again in the demo in a moment: a single password field, which you use for Encrypt as well as for Decrypt. That has a consequence:

Who	What they need to have
You, to encrypt	the key
Your friend, to decrypt	exactly the same key
The eavesdropper	everything except the key — and then he gets nowhere

Before the two of you can exchange a single message, you both have to know the same secret already. That sounds obvious when your friend is sitting next to you on the sofa. It isn't, and at the bottom of this chapter you'll see why.

What's changed in 2000 years

Caesar had 25 possible keys. You can try them all by hand in fifteen minutes. AES256 has 2²⁵⁶ possible keys. Put every computer on Earth to work together, and they'll still be at it when the sun burns out. The principle is the same; only the math under the hood is incomparably smarter.

So that one idea above — one key, two directions — has stayed the same for two thousand years. What it takes in practice to make it watertight is what comes after the demo.

Try it yourself

Everything happens in your browser. Nothing is sent to the server.

Click Encrypt. The encrypted package appears in the box below — unreadable.
Click Decrypt. Your message comes back.
Now change one letter in the password and click Decrypt again. No message, just a refusal.
Put the password back. Click Flip one bit — the demo changes a single 0 into a 1 in the package. Click Decrypt. The seal is broken.
Encrypt the same message twice. Compare the two packages.

Message Password (the key is made from this) The encrypted package (in base64 — remember it from chapter 1)

Two improvements that got added

Everything above has been true since Caesar. But "one key, two directions" on its own isn't enough: the same message sent twice would come out looking the same twice, and you wouldn't notice if someone had fiddled with your ciphertext along the way. Two things were added for that, and you'll find both of them in the package the demo just handed you.

Two more words

IV (initialisation vector): A random number that's different for every message, so that the same message sent twice with the same key still produces two different ciphertexts. Otherwise someone eavesdropping would see: "hey, he sent that same message yesterday too".
Seal (GCM): A 16-byte check number hanging off the end of the ciphertext, calculated with the key. Change one bit along the way and the seal no longer matches, so decrypting is refused. GCM is the name of the AES mode that makes a seal like that.

What's inside that package

The package in the box below isn't just your encrypted message. It's four pieces one after the other, and the demo shows you the first two separately:

Piece	Secret?	What for
Salt	no	To turn your password into a key. You know it from chapter 3 — same trick, same reason.
IV	no	Makes sure the same message looks different every time.
Ciphertext	yes	Your message, encrypted. The only piece that hides anything.
Seal	no, but unforgeable	Breaks the moment one bit of the ciphertext changes.

In formulas. Watch the second line: it's the encryption formula from above, now with the IV added.

key = PBKDF2(password, salt)

ciphertext = AES(key, IV, plaintext)

seal = GCM(key, IV, ciphertext)

The IV: the same message, different every time

Look at the second formula. AES gets not only the key and your message, but the IV as well. Use the same IV every time and the same message with the same key always gives exactly the same ciphertext. That's the salt problem from chapter 3, in a different coat:

Message	IV	Ciphertext
I'm behind the gym…	`0a1b2c3d…`	`5d4c29d39a38…`
I'm behind the gym…	`0a1b2c3d…` (the same)	`5d4c29d39a38…` (the same!)
I'm behind the gym…	`9d8e7f6a…` (new)	`276598dfaf7f…`

Rows one and two: whoever is listening in sees the same package go past twice. He doesn't know what you sent, but he does know that you sent the same thing as yesterday — and sometimes that's already enough. Row three: new IV, and there's nothing left to recognise. That's why the demo draws a fresh IV on every click of Encrypt, and why in step 5 you saw two completely different packages. The IV doesn't have to be secret. It only has to be new.

The seal: one bit wrong and the door stays shut

The third formula makes the seal: a calculation over the whole ciphertext, with the key worked into it. The recipient does that calculation again and compares. If the seal matches, it decrypts. If it doesn't, nothing comes out at all — no "nearly right", no garbage, just a refusal. That's what you saw in step 4.

Why can't a tamperer simply recalculate the seal himself after changing a bit? Because the key is in the formula. Without the key he can flip bits all right, but he can't make a seal that matches. So you get two things at once: nobody can read what's inside, and nobody can touch it without it showing. That second one Caesar never had.

The problem Caesar already had

Caesar could whisper the key to his general before he left. You can do that too: whisper the password, or write it on a scrap of paper and pass it along. But how do you do that with a website in America you've never seen, which has to give you a secure connection within a second?

You can't just send the key along — then the eavesdropper reads it too and it's all for nothing. And you can't send it encrypted either, because encrypted with what? You'd need yet another key that you both already know. You're going round in circles.

This is called the key exchange problem, and it seemed unsolvable for centuries. Until in 1976 two mathematicians came up with something that sounds like a magic trick. That's the next chapter.

This is math: an operation that undoes itself

Why can one key go both ways? Because of an operation you only ever have to learn once: XOR, written as ⊕. It works on single bits, and the whole table fits right here:

a	b	a ⊕ b
0	0	0
0	1	1
1	0	1
1	1	0

Different gives 1, the same gives 0. Now take a bit and XOR the same thing onto it twice: 1 ⊕ 1 = 0, then 0 ⊕ 1 = 1 — back where you started. Try it with all four rows and it always works out:

(a ⊕ b) ⊕ b = a

That's your answer right there. Out of the key and the IV, AES makes a long stream of bits that looks utterly random, and your ciphertext is your message XOR that stream. Decrypting is XOR-ing the same stream onto it once more. Not an opposite operation — the same one. Hence one key, two directions.

This is Boolean algebra: calculating with true and false instead of with numbers, thought up by George Boole around 1850, well before a single computer existed. Every chip in the world is built out of it.