Post-Quantum Cryptography

Two quantum algorithms that matter

1. Shor's algorithm (1994)

Peter Shor showed that a quantum computer can factor large integers and compute discrete logarithms in polynomial time rather than the sub-exponential time classical computers need. The implication is immediate and total: RSA, Diffie-Hellman, and elliptic-curve cryptography all rely on these problems being hard. Shor's algorithm makes them easy — once you have a big enough quantum computer.

"Big enough" is the open question. Recent estimates put RSA-2048 at roughly 20 million noisy qubits with current quantum error-correction overhead, or about 4,000 logical (error-corrected) qubits. Real systems today have ~1,000 physical qubits with no usable error correction. The gap is large. It is also closing.

2. Grover's algorithm (1996)

Grover's gives a quadratic speedup for unstructured search. Concretely: brute-forcing an n-bit key takes 2^n classical operations but only 2^(n/2) quantum ones. The implication is subtler than Shor's:

• AES-128 drops to effective 64 bits of security — still brute-forceable nowhere, but uncomfortably close to within reach of state-level adversaries with quantum hardware that may exist someday.
• AES-256 drops to 128 bits — comfortably out of reach.
• SHA-256 drops to 128-bit preimage resistance — still infeasible to break.

The fix for Grover is also simple: double the key size. Symmetric crypto and hashes survive the quantum era essentially intact, just with bigger keys. This is why your TLS connection's AES bulk cipher is far less worrying than its RSA/ECDH key exchange.

What breaks, what doesn't

Notice the pattern: asymmetric crypto is the problem; symmetric crypto is mostly fine. That's why the entire post-quantum migration focuses on key exchange and signatures, not on the bulk encryption that follows them.

"Harvest now, decrypt later"

For ephemeral data — a weather forecast, a stock ticker — harvest-now-decrypt-later is uninteresting. For data with multi-decade sensitivity:

• Government communications and classified material (often 25- or 50-year retention requirements)
• Medical records, genetic data
• Trade secrets, formulas, drug discovery work
• Source code for long-lived products
• Diplomatic and intelligence communications
• Most financial transaction logs

For these, the migration timeline is now. Not in 2035. The cost of being slow is that every encrypted message sent today gets decrypted when capability arrives.

NIST's standards (finalized 2024)

NIST ran a public competition from 2016 to 2024, evaluating 82 submissions across multiple rounds of cryptanalysis. The final standards, published August 13, 2024:

A fourth algorithm, FALCON (now FN-DSA), is in the pipeline as FIPS 206 for signature use cases needing smaller signatures than ML-DSA. NIST also continues evaluating additional KEM candidates as backups in case lattice schemes ever fall.

"Why not just one?"

A reasonable question. The answer: diversification. All three NIST standards rely on different mathematical foundations:

• ML-KEM and ML-DSA are lattice-based — both leverage Learning With Errors.
• SLH-DSA is hash-based — relies only on the security of SHA-256/SHA-3.

If a major flaw is found in lattice cryptography over the next decade (it has been heavily studied for 30 years, but nothing is certain), SLH-DSA remains intact. The fallback already exists, deployable, standardized. This is a cryptographer's defensive posture: never have one foundational assumption holding up everything.

Hybrid deployment

The recommended near-term pattern is hybrid: run a classical algorithm (X25519, P-256) and a post-quantum algorithm (ML-KEM) in parallel, combine the resulting keys. The connection is safe as long as either is unbroken. If ML-KEM is later found to have a flaw, the classical algorithm still protects you; if Shor arrives tomorrow, ML-KEM still protects you.

This is what TLS 1.3 deployments are doing in 2024–2025. Google deployed X25519MLKEM768 across Chrome and most Google properties starting in 2024. Cloudflare followed. Apple announced PQ3 for iMessage in early 2024 using a similar hybrid construction. Most TLS handshakes today are already post-quantum-hybrid.

A timeline

What this means operationally

• Inventory your cryptography. Where does your organization use RSA/ECDH/ECDSA? You can't migrate what you can't find. CISA and NIST have templates.
• Prefer agile crypto APIs. Code that calls libsodium.crypto_kx or OpenSSL EVP with the algorithm abstracted is easier to migrate than code that hardcodes "RSA-2048."
• Enable hybrid TLS in your servers (nginx, Apache, NGINX, AWS ALB, CloudFront) as it becomes available. Several CDNs and cloud providers already offer it.
• Treat long-lived signatures specially. Code signing for embedded devices that ship for 20 years — consider SLH-DSA or hybrid with SLH-DSA today.
• Watch the SSH ecosystem. OpenSSH 9.x added hybrid PQ key exchange. AWS ALB supports it. Update on a normal cadence.
• Don't panic about symmetric crypto. AES-256 and ChaCha20 remain fine. Most of your TLS bulk encryption survives unchanged.