The algorithms replacing RSA and ECC before quantum computers can break them.
In August 2024, NIST published the first finalized post-quantum cryptography standards: ML-KEM for key encapsulation, ML-DSA for digital signatures, and SLH-DSA as a hash-based signature fallback. Cloudflare, Google, Apple, AWS, and major TLS libraries have shipped support since then. The migration is happening now, not after quantum computers arrive.
Post-quantum cryptography (PQC) refers to classical algorithms — running on classical computers — that are believed to resist attack by quantum computers. They don't use quantum mechanics themselves. They're called "post-quantum" because they replace algorithms that would be broken once large quantum computers exist.
Formerly CRYSTALS-Kyber. Used for key exchange. Three parameter sets: ML-KEM-512, ML-KEM-768, ML-KEM-1024, with security levels matching AES-128, AES-192, and AES-256 respectively. ML-KEM-768 is the default for most TLS use cases. Public keys are 1,184 bytes, ciphertexts are 1,088 bytes — much larger than RSA-2048's 256-byte public key but small enough for practical use.
Formerly CRYSTALS-Dilithium. Used for digital signatures. Three parameter sets at 128-bit, 192-bit, and 256-bit security. ML-DSA-65 is the common default. Public keys are about 1,952 bytes, signatures around 3,309 bytes — again much larger than ECDSA's ~64-byte signatures.
Formerly SPHINCS+. Hash-based, so its security rests only on the security of the underlying hash function. Slower and larger than ML-DSA but a conservative fallback if lattice assumptions ever prove weak.
Additional algorithms (FN-DSA based on Falcon, and others) are progressing through the standardization process. NIST is also running a separate on-ramp for additional signature schemes, since the diversity of signature options matters less for key exchange but more for different deployment contexts.
A lattice is a regular grid of points in high-dimensional space. The shortest vector problem (SVP) asks: given a lattice, find the shortest non-zero vector from the origin to a lattice point. In high dimensions (hundreds), this problem is believed to be hard for both classical and quantum computers.
ML-KEM and ML-DSA encode plaintexts as small perturbations of a lattice point. Recovering the plaintext requires solving a problem closely related to SVP. No known quantum algorithm gives an exponential speedup for this problem. Grover's algorithm provides only a quadratic speedup, which is countered by doubling key sizes.
The cryptographic community has been studying lattice problems for over two decades. No efficient attack has emerged despite serious effort. The confidence level is high but not absolute — a future algorithmic breakthrough could change the picture, which is why hash-based and code-based alternatives are standardized alongside.
Cloudflare started offering hybrid post-quantum TLS in 2019 using a draft of Kyber. By 2024, ML-KEM-768 was deployed across most of their edge. Chrome added X25519+ML-KEM-768 hybrid key exchange by default in 2024. Apple shipped post-quantum support in iMessage PQ3 in early 2024. AWS Key Management Service supports ML-KEM for key wrapping.
OpenSSL 3.5 (released 2025) includes ML-KEM, ML-DSA, and SLH-DSA by default. Libraries like BoringSSL, Bouncy Castle, and libsodium all have PQC support. Most of the major TLS 1.3 implementations now negotiate post-quantum key exchange when both sides support it.
Hybrid key exchange — combining classical X25519 with ML-KEM-768 — is the conservative approach. If ML-KEM turns out to have a hidden weakness, the classical X25519 leg still provides security. This costs more bandwidth but reduces migration risk.
If you run a TLS-terminating service: enable hybrid post-quantum key exchange. Cloudflare, AWS CloudFront, and most modern reverse proxies support this with a flag flip.
If you issue certificates: track the CA/Browser Forum timeline. Major CAs are issuing hybrid certificates. Sometime after 2030, quantum-vulnerable algorithms may stop being accepted in public certificates.
If you sign software: large signatures are a real constraint. ML-DSA signatures are roughly 50x larger than ECDSA. Code-signing pipelines may need to handle larger artifacts.
If you store long-lived encrypted data: start migrating. "Harvest now, decrypt later" attacks are already being run. Anything that needs to stay confidential past 2035 should be re-encrypted with post-quantum algorithms.