When will quantum computers break encryption?

No one knows precisely, but most estimates place a cryptographically relevant quantum computer (CRQC) — powerful enough to break RSA-2048 — 10 to 20 years away. NSA's CNSA 2.0 advisory (2022) requires national security systems to begin PQC migration by 2025, treating urgency as a planning assumption rather than waiting for certainty.

Is AES-256 quantum safe?

Yes, with current analysis. Grover's algorithm — the relevant quantum attack on symmetric ciphers — provides a quadratic speedup, effectively reducing AES-256's security from 256 bits to 128 bits. 128-bit security is still far beyond any practical attack. AES-256 does not need to be replaced; only asymmetric algorithms (RSA, ECC, ECDH) face existential quantum threats from Shor's algorithm.

What algorithms are post-quantum safe?

NIST finalized three PQC standards in August 2024: ML-KEM (FIPS 203) for key encapsulation, ML-DSA (FIPS 204) for digital signatures, and SLH-DSA (FIPS 205) for hash-based signatures. ML-KEM replaces ECDH; ML-DSA replaces ECDSA and RSA signatures. These are the algorithms to deploy for quantum resistance.

What is the difference between quantum cryptography and post-quantum cryptography?

Quantum cryptography (such as Quantum Key Distribution, or QKD) uses quantum mechanical properties — like photon polarization — to exchange keys securely, relying on physics rather than mathematical hardness. Post-quantum cryptography uses conventional computers running new mathematical algorithms that quantum computers cannot break efficiently. PQC runs on existing hardware; QKD requires specialized quantum channels.

Should I start migrating to post-quantum cryptography now?

Yes, if your data has a sensitivity lifespan beyond five to ten years. The 'harvest now, decrypt later' (HNDL) threat means adversaries can capture your encrypted traffic today and decrypt it once a CRQC exists. Medical records, financial data, trade secrets, and government communications are the highest-priority targets. Begin with an inventory of cryptographic assets and a plan to prioritize HNDL-sensitive data.

Post-Quantum Cryptography: NIST Standards Explained

Q: What is post-quantum cryptography?

Post-quantum cryptography (PQC) refers to cryptographic algorithms designed to remain secure against attacks from quantum computers. Current widely-used algorithms like RSA and ECC would be broken by a sufficiently powerful quantum computer running Shor's algorithm. PQC algorithms, like NIST's ML-KEM and ML-DSA, rely on mathematical problems that quantum computers cannot solve efficiently.

Introduction

Intelligence agencies are archiving today’s encrypted internet traffic — planning to decrypt it once a quantum computer powerful enough to break RSA becomes available. That moment may be a decade away. The window to protect your data from it is now.

This threat is why post-quantum cryptography exists, and it has a name: harvest now, decrypt later (HNDL). An adversary does not need a quantum computer today to benefit from quantum computing tomorrow. They capture your TLS sessions, your encrypted API traffic, your VPN tunnels, and store them. When the cryptographic relevant quantum computer (CRQC) arrives, they decrypt the archive. Medical records, trade secrets, attorney-client communications, and national security information stored in TLS sessions from 2024 could become readable in 2034.

Post-quantum cryptography (PQC) is the field of cryptographic algorithms designed to resist attacks from quantum computers running on conventional silicon. In August 2024, NIST finalized three PQC standards: ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205). These algorithms use mathematical problems — lattice-based and hash-based — that quantum computers cannot efficiently solve.

The practical question is not whether quantum computers will eventually arrive — NSA’s CNSA 2.0 advisory treats that as settled — but how to build a migration roadmap that prioritizes the right data at the right time. This article translates the NIST standards into a concrete action framework.

What Is Post-Quantum Cryptography?

Post-quantum cryptography refers to classical (software-based) cryptographic algorithms designed to be secure against both conventional and quantum computers. The term distinguishes it from quantum cryptography, which uses quantum mechanical effects (like photon polarization) and requires dedicated quantum channels — see what quantum key distribution (QKD) is for how that alternative works and why the NSA declined to endorse it.

PQC algorithms run on ordinary hardware — your existing servers, TLS libraries, and smartphones. The goal is to replace algorithms that quantum computers would break (RSA, ECDH, ECDSA) with algorithms based on mathematical problems quantum computers cannot solve efficiently.

The threat is specific. Shor’s algorithm (Peter Shor, 1994) can factor large integers and solve discrete logarithm problems in polynomial time on a quantum computer. This breaks RSA (which relies on integer factoring) and ECC (which relies on the elliptic curve discrete logarithm problem). Both RSA and ECC become insecure on a sufficiently powerful quantum computer. To understand how these algorithms compare today, read our guide on RSA vs ECC.

Symmetric encryption and hash functions are not similarly threatened. Grover’s algorithm provides a quadratic speedup for unstructured search, effectively halving the security bits of symmetric ciphers. AES-256 becomes equivalent to approximately 128-bit security — still completely secure for practical purposes. AES-256, SHA-256, and SHA-3 do not need replacement.

How Post-Quantum Cryptography Works

The Three NIST Standards (Finalized August 2024)

ML-KEM (FIPS 203) — Key Encapsulation Mechanism

ML-KEM (formerly Kyber) replaces ECDH and RSA-OAEP for key agreement. It is based on the Module Learning With Errors (MLWE) problem — a lattice mathematics problem believed to be hard for both classical and quantum computers.

ML-KEM comes in three parameter sets:

Set	Security Level	Public Key Size	Ciphertext Size
ML-KEM-512	NIST Level 1 (AES-128 equivalent)	800 bytes	768 bytes
ML-KEM-768	NIST Level 3 (AES-192 equivalent)	1,184 bytes	1,088 bytes
ML-KEM-1024	NIST Level 5 (AES-256 equivalent)	1,568 bytes	1,568 bytes

NIST recommends ML-KEM-768 for most applications. Note that these keys are significantly larger than ECC P-256 (64-byte public key). TLS certificates and network protocols will need to accommodate this size increase.

ML-DSA (FIPS 204) — Digital Signature Algorithm

ML-DSA (formerly Dilithium) replaces ECDSA and RSA for digital signatures. It is also lattice-based (Module-LWE and Module-SIS problems). ML-DSA-65 (Level 3) produces a 3,309-byte signature — much larger than a 72-byte ECDSA signature.

SLH-DSA (FIPS 205) — Hash-Based Signature

SLH-DSA (formerly SPHINCS+) is a stateless hash-based signature scheme. Its security relies entirely on hash function security — no lattice assumptions. It is the conservative backup: larger and slower than ML-DSA, but based on decades-proven hash function security. Use SLH-DSA when you need maximum conservatism in security assumptions.

The Hybrid Approach

During the transition period, both Google Chrome and Cloudflare have deployed hybrid key exchange: X25519Kyber768 combines classical ECDH (X25519) with ML-KEM-768 in a single key exchange. An attacker must break both to compromise the session. This protects against the HNDL threat while maintaining backward-compatible fallback. IETF is standardizing hybrid approaches via RFC drafts.

This video covers the foundations of post-quantum cryptography and why current algorithms are vulnerable. The migration timeline and NIST algorithm selection table above translate those foundations into decisions your organization needs to make now.

The migration path runs left to right — inventory cryptographic assets, classify by sensitivity and lifetime, deploy hybrid (classical + PQC), then retire classical components once PQC ecosystem matures.

Classical vs Post-Quantum Algorithms

Property	RSA / ECC (Classical)	ML-KEM / ML-DSA (PQC)
Quantum resistant	No	Yes
Security basis	Integer factorization / ECDLP	MLWE / MSIS (lattice)
Key size (128-bit security)	RSA-3072 / ECC P-256 (64 bytes)	ML-KEM-768 (1,184 bytes)
Signature size (128-bit)	~256 bytes (RSA) / 72 bytes (ECC)	~3,309 bytes (ML-DSA-65)
Performance	Fast, especially ECC	Slightly slower; improving rapidly
Standardized	Decades ago	NIST finalized August 2024
Deployment	Ubiquitous	Early adopter phase (2024–)

The most significant practical challenge is key and signature size. ML-KEM-768’s 1,184-byte public key compared to ECC P-256’s 64 bytes means PKI infrastructure, TLS handshakes, code signing pipelines, and DNSSEC zones all increase in size. MTU fragmentation needs attention in high-throughput environments.

Real-World Use Cases

Enterprise TLS migration: Forward-looking organizations are enabling hybrid TLS in their load balancers and API gateways now. Cloudflare’s post-quantum TLS is available to all customers. AWS, GCP, and Azure have published PQC roadmaps. Enabling X25519Kyber768 hybrid key exchange in your TLS termination layer protects against HNDL with zero impact on clients that do not support PQC yet.

Long-lived key pairs and certificates: Root CA private keys, code signing keys, and long-lived encryption keys are the highest-priority migration targets. A root CA key generated today may sign certificates still in use in 2035. If that key was created with RSA-3072 or ECDSA P-384, it becomes vulnerable when a CRQC arrives — but a key generated with ML-DSA-65 does not.

Government and defense: NSA’s CNSA 2.0 (2022) establishes a mandatory migration timeline. National security system software must support PQC by 2025 and use only PQC by 2030. Hardware security modules in national security systems must support PQC by 2030 and only PQC by 2033. These timelines are driving hardware vendors to release PQC-capable HSMs and TLS accelerators.

Common Mistakes to Avoid

Waiting for a CRQC before starting migration. The HNDL threat means the window for protecting sensitive data closed in the past, not the future. If an adversary already captured your VPN traffic from 2022, you cannot retroactively protect it. Start the inventory now; prioritize data with multi-decade sensitivity first.

Replacing symmetric algorithms unnecessarily. AES-256, SHA-256, and SHA-3 do not require replacement. Only asymmetric algorithms — RSA, ECDH, ECDSA, DH — are threatened by Shor’s algorithm. Migrating AES-128 to AES-256 is prudent; migrating AES-256 to a “quantum-safe symmetric cipher” is unnecessary and does not exist as a standardized category.

Deploying PQC without a hybrid fallback. Deploying ML-KEM-only and dropping ECDH compatibility will break connections from clients that have not yet updated. Use hybrid key exchange (X25519 + ML-KEM-768) during the transition period. The hybrid adds bytes to the handshake but keeps compatibility.

Ignoring key size impacts on infrastructure. ML-DSA-65 signatures at 3,309 bytes are 45× larger than ECDSA P-256 signatures. DNS records, code signing infrastructure, and TLS certificate chains will increase in size. Test your infrastructure for MTU and buffer size assumptions before a wide rollout.

Getting Started

Begin with an inventory of every place your systems use asymmetric cryptography: TLS certificates and the keys behind them, SSH host keys, code signing certificates, API authentication tokens (JWT with RS256 or ES256), GPG keys, and any protocol using RSA or ECC for key exchange or signatures.

After inventorying, classify each asset by its sensitivity lifespan and how long until it is naturally rotated. Long-lived root CA keys, VPN credentials protecting multi-year contracts, and medical records retained for decades are the highest-priority targets. Short-lived JWT tokens that expire in minutes are lowest priority — even if captured, they are useless before a CRQC could break them.

For TLS, the practical first step is enabling hybrid key exchange at your TLS termination layer. Most major TLS libraries (BoringSSL, OpenSSL 3.2+, Rustls) include X25519Kyber768 support. Enable it alongside your current ECDHE configuration — clients that support it will negotiate hybrid; others fall back to ECDHE.

To understand the classical algorithms PQC is designed to replace, read RSA vs ECC: Choosing the Right Public Key Algorithm. For the hardware infrastructure that stores long-lived PQC keys securely, see hardware security modules explained. For a step-by-step guide on planning this transition, see our PQC Migration Checklist.