Asymmetric encryption
Say you buy a thousand identical padlocks, open them all and hand them out to everyone you know. The only key that fits them, you keep. If someone wants to send you something secret, he puts it in a box, clicks one of your padlocks onto it and posts it. From that moment on he can't get it open again either — only you can. A lock like that doesn't exist in metal. In math it does, and it's something other than what you did in the previous chapter: there, two people agreed a key together; here, someone sends you something secret directly without the two of you ever having agreed on anything.
Words you might need
- Key pair
- Two keys that mathematically belong together and are made together. Whatever one locks, only the other can open.
- Public key
- One of those open padlocks. You hand out as many as you like, and you're welcome to put it on your profile. Whoever sends you something secret puts it in a box and clicks your padlock onto it.
- Private key
- The only key that fits all those padlocks. It stays with you, always, and without it no box opens ever again — not even for the person who clicked it shut.
- Asymmetric
- Two different keys for locking and unlocking. The opposite of symmetric, where it's the same key.
- RSA
- The first system that could do this, from 1977, named after its three inventors Rivest, Shamir and Adleman. It works with prime numbers that are hundreds of digits long.
Not to be confused with the previous chapter
Both of them solve the same awkwardness — keeping secrets with someone you couldn't hand a key to beforehand — but they do it in a different way, and that difference gets everybody muddled. Including people who ought to know better.
| Agreeing a key (chapter 6) | Asymmetric encryption (here) | |
|---|---|---|
| What happens | the two of you arrive at one shared secret | someone encrypts something for you |
| Who takes part | both of you, at the same time | the sender alone; you don't have to be there |
| What you get | a shared key, which you then use with AES | a ciphertext, straight away |
| The key pair | belongs to that one exchange | is yours, and stays yours |
How it flips the roles
| Symmetric (chapter 5) | Asymmetric (this chapter) | |
|---|---|---|
| Keys | one, and you have to share it | two, and one may be seen by anyone |
| Agree in advance | yes, over a secure channel | nothing |
| Speed | lightning fast | slow |
| How big can the message be? | unlimited | very small — smaller than the key |
Two uses, and they are not the same operation
A key pair gets used in two ways, and it's worth keeping them apart — they're mixed up constantly, textbooks included.
| Encrypting | Signing | |
|---|---|---|
| Who starts | anyone who wants to send you something | only you |
| With which key | your public one | your private one |
| Who can do the other direction | only you, with your private one | anyone, with your public one |
| That's called | decrypting | verifying, not decrypting |
| What for | secrecy | proving it was you |
The rule you often hear — "whatever you encrypt with one key, you can only decrypt with the other" — isn't right. It holds for bare RSA and nowhere else. In the elliptic-curve systems, "encrypting with the private key" doesn't even exist: a signature is a pair of numbers that the message can't be pulled back out of. Verifying isn't decrypting, it's an equation that either checks out or doesn't.
The rule that does hold everywhere is this one: the private key does something only its holder can do; the public key lets everyone aim that at something or check it. Signing is what chapter 8.1 is about.
Two families, and a handful of names
There are several ways to make a key pair. Two of them carry almost everything you use today, and each gets a part of its own after this.
| Family | Rests on | Agreeing a key | Signing | Encrypting |
|---|---|---|---|---|
| RSA | factorising into primes | — | RSA-PSS | RSA-OAEP |
| Elliptic curves | counting backwards on a curve | ECDH | ECDSA, EdDSA | rarely |
| Primes mod p | the discrete logarithm | DH (chapter 6) | DSA — withdrawn | — |
| Lattices | finding the shortest vector | ML-KEM | ML-DSA | — |
Two things stand out in that table. There isn't a single family that can do everything — every column wants its own algorithm. And DSA is listed as withdrawn: the American standards body NIST took it out of the standard for new signatures in 2023, and left it in only so old ones can still be checked. The bottom row is the newest one and is about the quantum computer; more on that later.
What sticks with people. Ask someone who does this for a living what pulled them in, and the answer is surprisingly often about this one chapter. Not about the formulas, but about the lopsidedness: a SIM card half a centimetre across works out something that all the data centres in the world together cannot undo. That something so small can hold off something so large is not obvious, and it is not a trick of better machines. It is a property of the mathematics itself.
This is math: complexity
Everything in this chapter hangs on one kind of sum: one you do forwards in a fraction of a second and backwards not in a thousand years. Such a sum is called a one-way function. You have already seen two of them — multiplying primes in chapter 7.1 and adding points in chapter 7.2 — and they look nothing alike except in that lopsidedness. The subject that measures how much work a calculation costs is complexity theory, and it measures not in seconds but in how fast the work grows as your input gets bigger. Double the key and the work of encrypting doubles, while the work of cracking it becomes a few billion times greater. That is where your security lives.
And now the uncomfortable part. Not one one-way function has been proven to be one. Nobody has ever shown that factoring large numbers really has to be hard; all we know is that so far nobody has managed it. That question is tied to the most famous open problem in computer science, P versus NP, with a million dollars on it since 2000. If it is ever resolved the wrong way, half of this site falls silent. That is not a doomsday scenario to fear, but it is worth knowing: modern cryptography rests not on a proof, but on fifty years of failed attempts.