The Public-Key Idea

The last topic left us with a snag. Encryption with one shared key works beautifully, but both people first have to hold the same secret key — and getting that key to the other person, across the internet, is the very problem we were trying to solve. You need a safe channel to share the key, but the key is what you needed to make the channel safe. It is a chicken-and-egg loop.

Public-key encryption breaks the loop with a clever twist. Instead of one shared key, each person has two matched keys that work as a pair — one they hand out to the whole world, and one they keep entirely to themselves. This is also called asymmetric encryption, because the two keys play different roles. From here on we'll use both terms.

Picture an open padlock. Olivia mails copies of her open padlock to anyone who asks. To send her something secret, you put it in a box, snap her padlock shut, and send the box back. Only Olivia has the little key that opens that padlock — and notice she never had to mail that key anywhere. That mailed-out padlock is the public key; the key that stays in her pocket is the private key.

Two Matched Keys

The heart of the idea is that the two keys are a matched pair, and they are not interchangeable. What one key locks, only the other key can unlock. They are generated together, by math, so that each one undoes only the other — and no one can work out the private key just by looking at the public one.

Olivia's public key is the one she gives away. She can post it on her website, email it to strangers, print it on a poster — it does not matter who has it. Her private key is the one she guards and never shares with anyone. The whole scheme rests on that one key staying secret.

Anyone Can Lock, Only You Can Open

Here is the part that feels backwards at first. To send Olivia a secret message, you scramble it using her public key — the one everybody has. Once it is locked that way, her public key cannot unlock it again. Only her private key can.

That is why publishing the public key is perfectly safe. It can only lock things to Olivia; it can never open them. An attacker who grabs a thousand copies of her public key still cannot read a single message, because reading requires the private key she never let out of her hands.

Compare this to the shared-key approach from the last topic, where the one key both locks and unlocks. There, the key had to be a secret between two people. Here, the locking key is public and only the unlocking key is secret — and that single difference is what makes the whole thing work.

Solving the Key Handoff

Now look back at the chicken-and-egg problem. With public-key encryption, no shared secret ever has to travel across the network. The thing that gets sent around — the public key — is allowed to be seen by anyone, so it does not matter if it is intercepted on the way.

This is what lets two complete strangers set up security with no prior arrangement. When Olivia's browser connects to a website it has never visited, the two have never met and share no secret. The website proves its identity with its public key, and the two sides use public-key math to agree on a fresh shared key that only they know — without ever sending that key across the network. Security gets established from a cold start — which is the foundation of the padlock you see when you visit a secure website (Chapter 5).

Why We Still Use the Shared Key Too

There is a catch worth being honest about: the math behind public-key encryption is slow. Scrambling a whole video call or a large download with it directly would be painfully sluggish.

So in practice the two methods team up. Public-key encryption is used for one quick job — to safely agree on a fresh shared key while the two sides are still strangers. Once both sides hold that shared key, they switch to the fast shared-key (symmetric) encryption from the last topic to do the heavy lifting of the conversation. Public-key solves the handoff; shared-key carries the load. This handshake is roughly how a secure web connection begins, which we'll walk through in Chapter 5.