Post-Quantum Cryptography: A Practical Primer
The standards are final, the migration clocks are ticking, and your TLS traffic is probably already using post-quantum key exchange. Here's what the algorithms actually do, what's deployed, and what you should do about it.
Someone is recording your TLS traffic right now. Not because it’s interesting today — because it might be interesting in ten years.
The threat model has a name: Harvest Now, Decrypt Later. Nation-states capture encrypted data in bulk, store it cheaply, and wait for a cryptographically relevant quantum computer to break the maths underneath. Your traffic doesn’t need to be classified. It just needs to still be confidential when the decryption becomes possible. Healthcare records, financial transactions, long-lived credentials, trade secrets with a shelf life — if the data outlives the algorithm protecting it, HNDL is already your problem.
NIST decided this was urgent enough to spend eight years running a competition. On August 13, 2024, they published the results.
Three standards
FIPS 203 — ML-KEM. Module-Lattice-Based Key-Encapsulation Mechanism. Derived from CRYSTALS-Kyber. This is the TLS workhorse — the algorithm that protects key exchange, which is where HNDL hits hardest. Three parameter sets: ML-KEM-512, ML-KEM-768, and ML-KEM-1024, in ascending order of security. Key generation and encapsulation are roughly an order of magnitude faster than RSA. The trade-off is bandwidth: a hybrid X25519+ML-KEM-768 handshake adds roughly 2.3 KB total — about 1.2 KB from the client, 1.1 KB from the server.
FIPS 204 — ML-DSA. Module-Lattice-Based Digital Signature Standard. Derived from CRYSTALS-Dilithium. Its security relies on the Module Learning With Errors and Module Short Integer Solution problems, using a Fiat-Shamir with Aborts construction, where the signer repeatedly samples a candidate signature and rejects any candidate whose acceptance would cause the output distribution to leak information about the private key. Three parameter sets: ML-DSA-44, ML-DSA-65, ML-DSA-87. Signing is roughly ten times faster than RSA-2048. Signatures are larger: 2,420 bytes for ML-DSA-44, 3,309 bytes for ML-DSA-65, 4,627 bytes for ML-DSA-87 — compared to 64 bytes for Ed25519. You’re trading compactness for quantum resistance.
FIPS 205 — SLH-DSA. Stateless Hash-Based Digital Signature Standard. Derived from SPHINCS+. The conservative choice. No lattice assumptions, no number theory — security reduces to specific properties of hash functions. Signatures range from 8 to 50 KB across twelve parameter sets. Slower than ML-DSA, much larger signatures, but the simplest security argument of any post-quantum scheme. If you trust SHA-2 and SHA-3, you can trust SLH-DSA — different parameter sets use SHA-256 or SHAKE256, but the security argument is the same.
Two more are in the pipeline. FN-DSA (derived from Falcon) had its draft standard expected in 2025. HQC — a code-based key encapsulation mechanism on a different mathematical foundation from ML-KEM — was selected in March 2025, with a draft expected in 2026 and finalisation around 2027.
How SLH-DSA works — the part most primers skip
The three standards above share a concern: ML-KEM and ML-DSA both rely on the hardness of problems in module lattices — Module-LWE for key exchange, Module-LWE and Module-SIS for signatures. The problems are related. A sufficiently broad breakthrough in lattice mathematics could weaken both schemes, even if breaking one doesn’t automatically break the other. SLH-DSA exists as the insurance policy. Its security assumptions are different, older, and more conservative. Understanding why requires looking inside.
WOTS+ — Winternitz One-Time Signature Plus — is the foundation. It can sign exactly one message per key pair, and it does so using only hash function evaluations. No modular arithmetic, no elliptic curves. The limitation is obvious: one key, one signature.
FORS — Forest of Random Subsets — solves half the problem. FORS is a few-time signature scheme that can securely sign a bounded number of messages per key. The overall SLH-DSA scheme supports up to 2^64 signatures per key pair. When you sign a message with SLH-DSA, the message is hashed to a digest, and FORS signs that digest. The FORS public key is then authenticated by a WOTS+ signature.
Hierarchical Merkle trees solve the rest. Multiple layers of Merkle trees — a structure the specification calls a “hypertree” — chain together large numbers of WOTS+ key pairs under a single root public key. Each layer of the tree authenticates the layer below it. The root of the topmost tree, combined with a public seed, forms your public key. To verify a signature, you walk the tree from the FORS signature at the bottom up through WOTS+ signatures at each layer to the root.
The result is a signature scheme that supports an enormous number of signatures from a single key pair without tracking state. That last point matters. The related stateful scheme XMSS (RFC 8391) illustrates the problem SLH-DSA solves. XMSS is stateful — it maintains a counter of which one-time keys have been used, and if that state is ever lost, duplicated, or corrupted, security collapses. SLH-DSA avoids this entirely. FORS tolerates controlled key reuse below a security threshold, which means the signer never needs to remember what it signed before. In any deployment where state management is fragile — distributed systems, HSMs, high-availability clusters — statelessness is not a convenience. It’s a safety requirement.
One common simplification to correct: SLH-DSA’s security does not rest on hash preimage resistance alone. The formal security proofs require several distinct hash function properties — preimage resistance, multi-target collision resistance, and decisional second-preimage resistance among them. The accurate statement is that security reduces to properties of the hash function, with no additional algebraic assumptions. That’s still a remarkably clean foundation compared to lattice-based schemes.
What’s already deployed
The transition is not hypothetical. You’re probably using post-quantum cryptography right now.
Cloudflare reported in October 2025 that over 50% of human-initiated TLS traffic to their network was using hybrid X25519+ML-KEM-768 key exchange. Chrome 131 and Firefox 132 both negotiate this by default on desktop. The handshake combines a classical X25519 key exchange with a post-quantum ML-KEM-768 exchange — if either algorithm holds, the session is secure. This is the hybrid approach: belt and braces.
Signal shipped PQXDH — Post-Quantum Extended Diffie-Hellman — in September 2023, combining X25519 with CRYSTALS-Kyber-1024. The protocol explicitly targets HNDL: as long as either X25519 or Kyber remains unbroken, the session keys are protected. Signal conversations — new and progressively upgraded existing ones — are resistant to harvest-now-decrypt-later attacks, though the protocol does not defend against active impersonation by a quantum-capable adversary, a threat that remains theoretical.
Certificates are the remaining gap. Key exchange is post-quantum; authentication is still classical. Google is developing Merkle Tree Certificates as a PQ-compatible replacement for parts of the X.509 ecosystem, with a feasibility study in 2025–2026 and CA onboarding targeted for Q3 2027. Hybrid certificate proposals — ECDSA paired with ML-DSA — are in IETF drafts but not yet deployed. For now, you’re quantum-resistant against passive eavesdroppers (HNDL) but not against active man-in-the-middle attacks by a quantum adversary. Given that no such adversary exists yet, this is a reasonable ordering of priorities.
What the regulators are saying
NSA CNSA 2.0 sets the pace for national security systems: new acquisitions must be post-quantum-compliant by January 2027, legacy systems phased out by 2030. Hybrid approaches are permitted as a transitional measure, but the stated end goal is pure post-quantum cryptography across all national security systems by 2035.
US federal agencies have been submitting quantum-vulnerable cryptographic inventories to CISA and the Office of the National Cyber Director since May 2023, with annual updates required. FIPS 140-2 validation sunsets in September 2026 — after that, only FIPS 140-3 validated modules are acceptable for federal procurement.
The EU recommended national transition roadmaps by end of 2026 (a non-binding Commission Recommendation, with binding legislation under consideration), high-risk use case migration by 2030, and full transition by 2035. The UK NCSC follows a three-phase structure: planning completed by 2028, high-priority migration executed between 2028 and 2031, full migration by 2035.
Enterprise migration timelines depend on organisational complexity. An analysis in MDPI’s Computers journal estimated 5–7 years for small organisations, 8–12 for medium, and 12–15 or more for large enterprises. If your organisation is in the latter category, the planning window is already open.
What you should do today
Inventory your cryptographic dependencies. OpenSSL version, TLS configuration, certificate chains, any hardcoded algorithm choices. You cannot migrate what you have not mapped. NIST’s own guidance starts here, and so should you.
Enable hybrid key exchange. If your TLS stack is reasonably current, X25519+ML-KEM-768 may already be negotiated by default. Verify it. If not, most modern TLS libraries — OpenSSL 3.5, BoringSSL, AWS-LC — support it with minimal configuration. This is the highest-value, lowest-friction step you can take.
Start planning certificate migration. Post-quantum certificates are not ready yet, but the timeline is 2027. Map your certificate lifecycle — issuance, renewal, pinning, trust chains — so you are not scrambling when PQ certificates arrive.
What you can wait on
Don’t rip out Ed25519 or ECDSA. Hybrid is the transition path, not a hard cutover. Don’t deploy PQ-only anything — no production system should depend solely on algorithms this young. Don’t panic about FN-DSA or HQC — they’re useful additions, not urgent replacements.
If you want to stay current, Bill Buchanan and Bas Westerbaan are two of the clearest voices on PQC — Buchanan writes prolifically on the cryptographic detail, Westerbaan is behind much of Cloudflare’s post-quantum deployment. Both are worth following on LinkedIn.
The hybrid approach exists precisely to buy you time. The responsible move is to use it — protect your key exchanges now, plan your certificate migration for 2027, and let the ecosystem mature before making irreversible choices.
The standards are final. The deployment is underway. The algorithms are young — active research continues on implementation security, and NIST standardised HQC as a backup KEM precisely because cryptographic agility matters. But the direction is clear, the tooling exists, and the regulatory clocks are running. The only question is whether your migration starts by design or by deadline.