Post-quantum cryptography, without the panic.

A founder I respect asked me, on a call last month: do I have to do something about quantum? They run a fintech with seven years of customer data on the wire. They had read a scary blog post. They wanted to know if they should panic, ignore it, or do something in between. The honest answer is: something in between, and it's smaller than the panic posts say but larger than zero. This post is that answer, written for engineers who are not cryptographers but who own systems that hold long-lived secrets.

I'll define the threat, walk through what NIST actually shipped in 2024, give you the practical numbers, and end on the one engineering habit that matters more than picking the right algorithm. No math is required; some math is shown.

What 'quantum breaks crypto' actually means

The phrase is too broad to be useful, so let's be precise. A sufficiently large quantum computer running Shor's algorithm would, in polynomial time, factor large integers and solve discrete logarithms. That kills RSA, Diffie-Hellman, and elliptic-curve crypto — the three primitives that anchor most of the public-key cryptography in production today, including the TLS handshake your browser ran to load this page.

Grover's algorithm is the other one people quote. It speeds up brute-force search quadratically, which means a symmetric key of n bits has roughly n/2 bits of effective security against a quantum attacker. AES-128 becomes AES-64-equivalent (uncomfortable), AES-256 becomes AES-128-equivalent (still fine). The fix for symmetric crypto is mostly: use AES-256. The hard problem is the public-key side.

Why this is already a problem, not a 2032 problem

The argument that always wakes engineers up is harvest-now, decrypt-later. A patient adversary doesn't need a quantum computer today. They need a hard drive. They capture the encrypted traffic now — VPN tunnels, TLS sessions, archived backups, federated message logs — store it cheaply, and decrypt it the day a Shor-capable machine exists.

That changes the calculus. The question is no longer when will the quantum computer arrive? The question is: what data, encrypted with today's keys, will still matter on that day? Health records. Identity documents. Legal contracts. State secrets. Trade secrets that need to stay secret for two decades. For systems that protect data with a long secrecy horizon, the threat is already live, because the ciphertext is being collected today.

For ephemeral data — a session token that expires in an hour, the price you paid for coffee — harvest-now is mostly theatre. The data is worthless by the time it's decrypted. The seriousness of the threat is exactly proportional to how long your secrets need to remain secret.

What NIST actually shipped

After an eight-year public competition, NIST finalized three post-quantum standards in August 2024. These are real, deployable, and already showing up in OpenSSL, BoringSSL, libsodium, AWS KMS, Cloudflare's edge, and Chrome's TLS handshake. The names are awful; live with them.

• ML-KEM (FIPS 203) — the key-encapsulation algorithm, derived from Kyber. This replaces RSA/ECDH for key exchange. When two parties agree on a shared symmetric key over the open internet, ML-KEM is the new way to do it.
• ML-DSA (FIPS 204) — the digital-signature algorithm, derived from Dilithium. This replaces RSA/ECDSA for signing. Code signatures, JWTs, document signatures, certificate signatures — all of it.
• SLH-DSA (FIPS 205) — a stateless hash-based signature scheme, derived from SPHINCS+. Slower and bigger than ML-DSA, but it relies only on hash-function security, so it survives even if lattices turn out to be quantum-weak. Belt-and-braces for high-assurance signing.

Two of these (ML-KEM, ML-DSA) are built on lattice problems — specifically, learning-with-errors over module lattices. The short version of why that's a good bet: there is no known efficient quantum algorithm for the underlying lattice problems, and the best classical attacks have been studied for decades without falling. It's not a proof; it's a well-stress-tested wager. SLH-DSA is the hedge: if the lattice wager loses, hash-based signatures still stand.

The catch — keys and signatures got bigger

There's a tax. Post-quantum keys and signatures are larger than what they replace, sometimes by a lot. Round numbers, today:

• Ed25519 signature: 64 bytes. ML-DSA-65 signature: ~3,300 bytes. About 50× larger.
• X25519 public key: 32 bytes. ML-KEM-768 public key: ~1,184 bytes. About 37× larger.
• SLH-DSA signature: 8,000–50,000 bytes depending on parameters. Yes, really.

For a TLS handshake this is manageable — a one-time cost at connection setup. For a system that puts a signature in every HTTP header, or a token in every URL, the size delta matters. Plan for it. Measure it on your real traffic before swapping anything in.

What 'migrate to post-quantum' actually looks like

Nobody serious is recommending a clean swap from classical to PQ on a single deploy date. The migration that's actually happening, at the companies you've heard of, has three stages and they're all incremental.

1. Inventory. Find every place your system relies on RSA, ECDSA, ECDH, DH. TLS endpoints, JWT signers, code signers, SSH hosts, OIDC providers, hardware-security-module keys, S3 client-side encryption, federated tokens between services. You cannot migrate what you cannot see. Most teams discover the inventory is twice as large as they expected.
2. Hybrid first. The current best practice is hybrid key exchange — run X25519 and ML-KEM together; the session key is derived from both. If lattices break tomorrow, the X25519 half still holds. If a future flaw is found in X25519, the ML-KEM half holds. Hybrid is what Cloudflare and Chrome are already doing on the public internet; it's the path of least regret.
3. Crypto-agility before algorithm choice. The single biggest engineering win is not picking ML-KEM versus something else. It's making your system able to swap the algorithm without rewriting your application. If your code says RSA in 400 places, you have a code problem, not a crypto problem. More on this in the next post.

Who should be moving now, and who can wait

Triage, rough but useful.

• Move this year: anyone holding long-lived secrets (health, identity, legal, financial archives), anyone whose ciphertext is realistically being captured (telecoms, VPN providers, anything crossing hostile networks), and anyone signing software or firmware updates that need to be verifiable a decade from now.
• Plan this year, move next: SaaS with sensitive customer data, B2B platforms with multi-year contracts, anyone doing federation or single-sign-on across organisations.
• Stay informed, no rush: consumer apps with ephemeral data, internal tools behind a corporate VPN, anything whose secrets are worthless within months.

For the agent systems we build at GOGOGO LLC the relevant question is narrower: which secrets does an agent hold, and for how long? An ephemeral session token an agent uses for the next 30 seconds is in the bottom bucket. A signing key that authenticates an agent's traceable output over years is in the top bucket. The same product can have both, which is exactly why crypto-agility — not algorithm choice — is the operationally interesting problem.

“Post-quantum is not an emergency, and it's not theatre. It's a deadline whose date you don't know, on a problem whose worst case is already happening — the ciphertext is being saved right now. The right posture is: inventory first, hybrid second, agility everywhere.”

Where this goes next

The interesting work isn't picking ML-KEM. The interesting work is building systems where the algorithm is a swappable component — where the day a NIST standard gets superseded (and it will), the migration is a config change, not a rewrite. That discipline has a name — crypto-agility — and it's the subject of the next post. The one after that is about what all of this means specifically for systems where many agents share, sign, and verify state. If your products are running today, this is the right time to start the inventory. Not too early. Not too late. More on how we think about building at gogogollc.com.