Start here — what "post-quantum" actually means
PQC is post-quantum cryptography. It runs on ordinary computers — the one you are reading this on will do both halves of this page in a few milliseconds. The "quantum" in the name is the attacker it is built against, not the machine it needs.
It is not a stronger lock. It is a lock built on a different problem. Nothing on this page will tell you post-quantum cryptography is stronger, because that is not what changed — and it is the single most common thing people get wrong about it.
When two people want to keep something private, they first have to agree on a shared secret — bytes both of them end up holding — even though everything they send each other can be read by anyone in between. That secret is not the message. A real application takes it and derives the keys that actually protect the conversation. Agreeing on it is the step this page is about, and your browser does it every time you load a page over HTTPS.
The way it is done today rests on one particular maths problem being hard to undo. Quantum computers exist; one big enough to undo that problem does not, and is expected to be able to. So people built other ways to agree on a secret that rest on a different hard problem — one that machine is not expected to help with. Those are what "post-quantum" means.
What the four panels below do, and the words they use
The same job done twice — once the way it is done today, once the post-quantum way, with real cryptography both times. Then the one thing that measurably changed, one byte broken on purpose, and one thing neither method does for you.
- Shared secret
- Bytes both participants end up holding. Not the message: an application derives the keys that protect the conversation from it.
- Public key
- Something you may hand to anyone, and that an observer may copy.
- Ciphertext
- Here, ML-KEM's public reply — the "sealed box". It is how both sides arrive at the shared secret. It is not the conversation.
- Byte
- A unit of size. Nothing on this page asks you to do binary arithmetic.
- Authentication
- Checking who you are talking to. A separate job — see panel 4.
Panel 1 · Classical method · X25519
Two people agree on a secret, in the open
Rae and Dev have never met and share nothing in advance. Each sends the other one value, in public. Each then combines what they received with something they never sent. Both end up holding the same secret.
Here is the part that matters. Everything an eavesdropper needs is in the two values above — they crossed the wire in the clear. Today, having them does not get you the secret. A quantum computer large enough to work it out from them is expected to be able to; no such machine has been built.
Why a quantum computer would help here
Not because it tries every possibility faster. The particular problem this method rests on turns out to have a quantum shortcut — a way to get the answer directly rather than by searching. That shortcut has a name and a mechanism, and it is a lab of its own: Shor.
Panel 2 · Post-quantum method · ML-KEM-768
The same thing, on a different hard problem
Same two people, same goal, same page layout. This time Rae publishes a key, Dev seals a box to it, and Rae opens the box. Both end up holding the same secret. This is ML-KEM-768 — the real thing, from the published standard, running in this tab.
One thing to be clear about, because the word "box" invites it: nothing of Dev's is inside that box. Dev does not put a message or a password in it. Sealing the box is what produces the fresh secret on Dev's side, and opening it is what reproduces the same secret on Rae's. It is a way to agree, not a way to send.
A quantum computer is not expected to help with the problem this one rests on. That is the whole change. The secret is the same size, the two sides still match, and the job is the same job.
Why these bytes are not panel 1's bytes
They are not meant to be. These are two separate exchanges run independently; each one agrees with itself, which is the only thing either is trying to do. Two different methods reaching the same secret as each other would be a bug, not a feature.
What actually changed
Bigger, on a different problem — and that is the whole list
Put the two panels side by side and there is exactly one difference you can measure: how many bytes crossed the wire. You can check this one with division.
This is not a footnote. Bigger messages are the real engineering consequence of the change: 1,184 bytes do not fit where 32 did, and a message that no longer fits is a message something along the way may refuse, truncate, or quietly negotiate away. That is the subject of Downgrade Wire.
It is not why today's deployments run both exchanges together
They do that to avoid betting everything on one assumption: ML-KEM is new, and if a weakness were found in it, a session that also ran X25519 has not been lost. Running both costs more bytes rather than saving them — it is a hedge against being wrong, not a fix for the size.
Panel 3
Break one byte
Take the sealed box from panel 2 and change a single byte of it on the way across. Then let Rae open it anyway. Watch what happens — and watch what does not.
ML-KEM did not report a failure. No error, no exception, no rejected message. Rae opened a box that had been tampered with and got back a perfectly well-formed secret that simply is not Dev's. The standard specifies that behaviour rather than an error.
So how does real software catch it?
Not by mailing the secrets to each other to compare — that would hand them to the eavesdropper. It catches it the next time the secret is used: each side sends a short value computed with the key (key confirmation), or the first real message carries an authentication tag the other side checks. Disagreeing keys fail that check immediately. What this panel shows is that the failure surfaces one layer up, and software that skips that layer never hears about it.
What goes wrong when real software forgets to check, in depth: KEM Trap.
Panel 4
Who sent that key?
Panel 2 had Rae publish a key and Dev seal a box to it. Try it once more, and this time pick who actually handed Dev that key.
Why now
Recorded today, read later
Someone records your connection this afternoon and keeps all of it: the public values the two sides exchanged, and the encrypted bytes of everything you said afterwards. They cannot read a word of it today. That is the point — they are not trying to. They put the whole recording on a disk, and they keep the disk.
Years later a large enough machine exists. They go back to the disk, use it on the recorded public values to work out that afternoon's shared secret, and then use that secret to decrypt the conversation they already have. Nothing about that afternoon can be changed afterwards: the bytes are on their disk, and the decision about which method protected them was made the day the connection opened.
That is the whole argument for moving before the machine arrives rather than after.
Which secrets this actually applies to
It only bites for information that still matters years from now — a medical record, the identity of a confidential source, research data under embargo — which is also why "migrate everything immediately" is the wrong answer. What you actually need to know is which of your secrets have a long life.
Where to go next, if you want to
You can stop here. The four panels above are the whole lesson; everything below is somebody else's lab.
- Harvest Timeline — how long you have, as arithmetic on three numbers.
- Harvest Vault — the recording and the later reading, shown end to end.
- PQ Chooser — if you have to pick something and defend the choice.
- Kyber Vault — this same ML-KEM, taken apart properly.
What is real here, and what this does not prove
This is a teaching demo, not production cryptography. Everything runs in your browser; no key here leaves this tab or outlives it.
- Not shown. Nothing here breaks X25519, and nothing here runs a quantum algorithm. "A large enough machine could undo panel 1" is a statement about a known result, linked rather than demonstrated.
- Not proved. That ML-KEM is secure. No lab can show that. What is shown is that it does the same job, at a different size, on a problem the known quantum shortcut does not apply to.
What is real, how it is checked, and what is left out
- Real. Every byte on this page comes from a published implementation of a published standard: ML-KEM-768 from FIPS 203, and X25519 from RFC 7748. Nothing is simulated, approximated or drawn to look right.
- Checked. The ML-KEM-768 figures are checked against NIST's published ACVP test vectors and the X25519 ones against RFC 7748's own worked example, with the difference between those two kinds of evidence written down in the repository rather than blurred together.
- Deliberately left out. How ML-KEM works inside. This page is the door, not the building, and the maths underneath is a lab of its own: Lattice Gentle builds up the lattice problem by hand, from nothing.