A security engineer at Cloudflare or Google can already tell you that a large fraction of the TLS handshakes crossing the public web carry two key exchanges bolted together: a classical X25519 and a lattice-based ML-KEM-768. That fact is where a lot of post-quantum interview questions start, because it proves the migration is running in production right now, not waiting in a standards draft. If you walk into a platform, security, or cryptography loop in 2026 and treat post-quantum as a future problem, you’ve already told the interviewer you haven’t looked.
The driver isn’t a quantum computer that exists today. None can factor a 2048-bit RSA key, and the sober estimates for one that can are still years to a decade-plus out. The threat that makes interviewers care is harvest now, decrypt later. An adversary who records encrypted traffic today can store it and break it whenever a large enough quantum machine shows up. Anything that has to stay secret for ten or twenty years, medical records, state secrets, long-lived credentials, is already exposed the moment it crosses the wire. So the mental model that earns points is that the confidentiality deadline for a lot of data sits in the past, not the future.
What Shor actually breaks, and what survives
Peter Shor’s algorithm solves integer factorization and discrete logarithms in polynomial time on a quantum computer. That kills RSA, finite-field Diffie-Hellman, and every elliptic-curve scheme (ECDH, ECDSA, EdDSA) in one stroke, because all of them rest on one of those two hard problems. A good candidate says this immediately, and names it as the whole reason asymmetric crypto needs replacing.
Grover’s algorithm is the other one, and it’s where people overreach. Grover gives a quadratic speedup on unstructured search, which halves the effective strength of symmetric primitives. AES-128 drops to roughly 64 bits of quantum security, which is uncomfortable, so the standard advice is to prefer AES-256. SHA-256 stays fine for most uses. The interviewer wants to hear that symmetric crypto and hashing survive with larger parameters, while public-key crypto has to be rebuilt on different math. Claiming a quantum computer breaks AES outright is a fast way to look shaky.
The three standards NIST finalized, and what each replaces
In August 2024 NIST published its first three finished standards, and the names changed from the research names most blog posts still use. FIPS 203 is ML-KEM, the key encapsulation mechanism formerly called CRYSTALS-Kyber. It replaces the key-agreement step, the part that settles on a shared secret. FIPS 204 is ML-DSA (formerly CRYSTALS-Dilithium), a digital signature scheme, and FIPS 205 is SLH-DSA (formerly SPHINCS+), a stateless hash-based signature kept as a conservative backup built on very different math. A fourth signature standard derived from FALCON, expected as FN-DSA, was still pending when these three landed.
Knowing which tool does which job is table stakes. A KEM is not a signature. You reach for ML-KEM to establish a session key in TLS or a messaging handshake, and for ML-DSA to sign a certificate, a firmware image, or a software artifact. Suggesting you’d sign something with Kyber reads as never having touched the primitives.
| Scheme | Type | NIST standard | Public key size | Signature or ciphertext size | Role in a system |
|---|---|---|---|---|---|
| X25519 (classical baseline) | Elliptic-curve key exchange | n/a | 32 bytes | 32-byte share | Broken by Shor; kept as the classical half of a hybrid |
| ECDSA P-256 (classical baseline) | Elliptic-curve signature | n/a | 33 to 65 bytes | about 64 bytes | Broken by Shor; the size bar everyone compares against |
| ML-KEM-768 | Lattice key encapsulation | FIPS 203 | 1,184 bytes | 1,088-byte ciphertext | Agrees on a session key; replaces the key-exchange step |
| ML-DSA-65 | Lattice signature | FIPS 204 | 1,952 bytes | 3,309 bytes | Default post-quantum signature for certs and artifacts |
| SLH-DSA-128s | Hash-based signature | FIPS 205 | 32 bytes | 7,856 bytes | Conservative backup on unrelated math; large, slow signing |
Why every serious deployment ships hybrids
The reason production systems don’t just swap in ML-KEM and call it done is confidence. Lattice cryptography is younger than RSA by decades, and while the analysis looks strong, nobody wants to bet ten years of traffic confidentiality on a scheme that might hide an unpublished weakness. A hybrid key exchange runs a classical algorithm and a post-quantum one together and mixes both shared secrets, so the session holds as long as either half holds. Break the lattice math tomorrow and X25519 still stops a classical attacker; break ECC with a quantum computer and ML-KEM still protects you. The deployed name to know is X25519MLKEM768, the concrete hybrid that Chrome, Cloudflare, and others turned on by default across 2024 and 2025.
Interviewers like to push here. “Why not go pure post-quantum and drop the classical half?” The answer that lands weighs the cost, a little extra handshake size and CPU, against the downside of a single point of failure in a young algorithm, and settles on hybrid as cheap insurance for the transition. Saying “we’ll retire the classical half once the post-quantum schemes have more years of scrutiny” shows you read this as a staged migration rather than a flag flip.
The size problem that reshapes protocols
Here’s the part that catches people who only read the headlines. Post-quantum keys and signatures are big. An X25519 public key is 32 bytes; an ML-KEM-768 public key is 1,184 bytes with an 1,088-byte ciphertext on top. That’s survivable for key exchange. Signatures are worse. An ECDSA P-256 signature runs about 64 bytes, while an ML-DSA-65 signature is 3,309 bytes and its public key nearly 2,000. A TLS certificate chain can carry several signatures and public keys, so a handshake that used to fit in two or three packets can balloon past ten.
This is why so much post-quantum work is really protocol surgery. Extra round trips from TCP slow start, QUIC’s anti-amplification limit that caps how much a server sends before it has validated the client’s address, embedded devices with kilobytes of RAM that suddenly have to buffer multi-kilobyte handshakes: these are the failures that actually bite, and they separate a candidate who has shipped this from one who has read about it. A sharp interviewer might ask where you’d begin a migration. The strong answer is key exchange first, because harvest-now-decrypt-later attacks the confidentiality of session keys, while a signature can’t be forged retroactively by a future quantum computer. You have more time on authentication than on encryption.
Crypto-agility, and the mistake the industry made once already
Ask an experienced engineer why this migration hurts and they point at every place someone hardcoded an assumption. Buffers sized for 256-byte signatures. Certificate fields with fixed lengths. Protocols with no version negotiation for the key exchange. Hardware security modules that only speak RSA and ECC. The industry lived this once, retiring SHA-1 and crawling off RSA-1024, and the lesson was that systems need crypto-agility, the ability to swap algorithms without re-architecting around them. If you can describe a design where the algorithm is a negotiated parameter instead of a baked-in constant, you’re answering the question behind the question.
Post-quantum is not quantum key distribution
A frequent trap: the interviewer asks whether you’d use quantum key distribution to solve this. QKD uses physics, photon states over dedicated fiber, to detect eavesdropping, and it needs special hardware and point-to-point links. Post-quantum cryptography is ordinary math running as software on the machines you already own. The NSA and the UK’s NCSC have both said plainly they favor post-quantum cryptography over QKD for national security systems, partly because QKD doesn’t scale to the internet and can’t authenticate anything by itself. Reaching for QKD when someone asks about PQC signals that you’ve conflated two different fields.
The questions, phrased the way they land
Across security, platform, and cryptography loops, the same handful show up with slight reskins:
- “What does a quantum computer break, and what survives with bigger parameters?”
- “Why bother with a hybrid handshake instead of pure ML-KEM?”
- “You’re moving a service off RSA. Do you start with encryption or signatures, and why?”
- “Our firmware signatures just grew from 256 bytes to several kilobytes. What breaks downstream?”
- “Design a certificate system that can change its signature algorithm without a forklift upgrade.”
None of these reward memorized acronyms. They reward someone who can hold two facts at once: that the cryptography is standardized and already shipping, while the genuinely hard part is the decade of code that assumed keys would stay small and algorithms would never change. Candidates who have moved a real system talk about buffer sizes and packet counts. The ones who haven’t talk about qubits.
Keep sharpening your system design:
