Post-Quantum Cryptography

Cryptographic algorithms designed to resist attacks from both classical and quantum computers. The term covers the replacement algorithms, the migration process, and the ecosystem changes needed before cryptographically relevant quantum computers arrive.

Why current cryptography breaks

Public-key cryptography (RSA, ECDSA, ECDH, Diffie-Hellman) relies on mathematical problems that are hard for classical computers: factoring large numbers and computing discrete logarithms. Shor's algorithm, running on a sufficiently large quantum computer, solves both in polynomial time. Once a CRQC exists, every RSA key, every ECDSA signature, and every ECDH key exchange becomes trivially breakable.

Symmetric cryptography (AES, ChaCha20) is largely unaffected. Grover's algorithm theoretically halves the effective key length, but the actual circuit requirements for breaking 128-bit keys are around 2^106 — no practical threat. See crqc-timeline for details.

The NIST standards

NIST finalized three post-quantum standards in 2024:

ml-kem (Module-Lattice Key Encapsulation Mechanism, FIPS 203) — formerly Kyber. Replaces ECDH for key exchange. Based on the Module Learning With Errors (MLWE) problem. Three security levels: ML-KEM-512, ML-KEM-768, ML-KEM-1024.

ml-dsa (Module-Lattice Digital Signature Algorithm, FIPS 204) — formerly Dilithium. Replaces ECDSA/RSA for signatures. Also based on MLWE. Three levels: ML-DSA-44, ML-DSA-65, ML-DSA-87.

SLH-DSA (Stateless Hash-Based Digital Signature Algorithm, FIPS 205) — formerly SPHINCS+. A hash-based signature scheme as a fallback in case lattice math is broken. Much larger signatures and slower, but relies only on hash function security.

Lattice cryptography in brief

ML-KEM and ML-DSA are both built on lattice problems — specifically, the hardness of finding short vectors in high-dimensional lattices with noise added. The "Module" prefix means they use structured (module) lattices for efficiency. The security argument: these problems have been studied for decades and no efficient quantum algorithm is known for them (unlike factoring/discrete log, where Shor's algorithm exists).

Lattice algorithms are actually simpler to implement correctly than ECC. No need for constant-time point multiplication, no curve-specific edge cases. The main trade-off is size: ML-KEM ciphertexts and ML-DSA signatures are larger than their classical counterparts.

Migration priorities

Per crqc-timeline, the recommended order as of April 2026:

1. Key exchange — deploy ML-KEM now. Any non-PQ key exchange is a potential active compromise vector. TLS 1.3 already supports ML-KEM via hybrid key exchange in Chrome and other browsers.
2. Signatures — deploy ML-DSA-44 directly, skip hybrid schemes. Hybrid adds complexity without proportional benefit now that lattice confidence is high.
3. File encryption — add PQ recipients to archival encryption. store-now-decrypt-later attacks make this urgent even before CRQCs exist.
4. Identity systems — blockchains and decentralized identity protocols need migration plans now. Late migration means choosing between compromise and bricking.
5. TEEs — no PQ alternatives exist yet. Downgrade to defense-in-depth, don't treat as a trust boundary.

The hybrid debate

Early migration guidance recommended hybrid schemes (classical + PQ combined) as a safety net: if the PQ algorithm is broken, classical still protects you. Valsorda now argues against this for signatures: hybrid adds implementation complexity, interoperability friction (18+ composite types), and delays pure PQ deployment. For key exchange, hybrid has already been deployed widely enough (Chrome ships it) that the transition path is clearer.

What's NOT threatened

• AES-128, AES-256, ChaCha20 — symmetric encryption is fine
• SHA-256, SHA-3, BLAKE3 — hash functions are fine
• HMAC, HKDF — fine (they use hash functions, not public-key math)
• Argon2, bcrypt, scrypt — password hashing is fine