The Quantum Threat to Current Encryption
Modern public-key cryptography — RSA, Diffie-Hellman, Elliptic Curve Cryptography — protects virtually all secure communications on the internet: HTTPS connections, SSH sessions, VPN tunnels, email encryption, digital signatures, and code signing. These algorithms are secure because solving the underlying math problems (integer factorization for RSA, discrete logarithm for DH/ECC) is computationally infeasible for classical computers.
Quantum computers operate on fundamentally different principles. Rather than processing bits that are either 0 or 1, quantum computers manipulate qubits that can exist in superpositions of states, and can exploit quantum interference and entanglement to solve certain mathematical problems exponentially faster than any classical computer.
In 1994, mathematician Peter Shor published an algorithm — now called Shor's algorithm — that can factor large integers and solve discrete logarithm problems in polynomial time on a quantum computer. A quantum computer running Shor's algorithm with enough stable qubits could break a 2048-bit RSA key or a 256-bit ECC key in hours or days, compared to the billions of years it would take classical computers.
No quantum computer capable of running Shor's algorithm against real-world key sizes exists today. However, national intelligence agencies, security researchers, and standards bodies unanimously agree that this is a matter of when, not if. NIST estimates a cryptographically relevant quantum computer (CRQC) could emerge by the mid-2030s. The urgency comes from the "harvest now, decrypt later" threat: adversaries are already archiving encrypted communications today, planning to decrypt them retroactively once quantum computers become available.
Understanding the Specific Quantum Computing Threats
Shor's Algorithm: Killing Asymmetric Cryptography
Shor's algorithm directly threatens all asymmetric (public-key) cryptosystems based on the hardness of:
- Integer factorization: RSA (all key sizes)
- Discrete logarithm over finite fields: Classic Diffie-Hellman (DH), DSA
- Elliptic curve discrete logarithm: ECDH, ECDSA, EdDSA
This means TLS key exchange (even with perfect forward secrecy), SSH host keys, code-signing certificates, and PGP keys are all vulnerable. Doubling the key size does not help — Shor's algorithm scales polynomially, so a quantum computer that breaks 2048-bit RSA also breaks 4096-bit RSA with only a modest increase in qubits and time.
Grover's Algorithm: Weakening Symmetric Cryptography
Grover's algorithm provides a quadratic speedup for searching unstructured data — including brute-forcing symmetric keys and hash preimages. A quantum computer using Grover's algorithm can search a 256-bit keyspace in the time a classical computer would search a 128-bit keyspace. This means:
- AES-128 → effectively 64-bit security against quantum attacks (inadequate)
- AES-256 → effectively 128-bit security against quantum attacks (still acceptable)
- SHA-256 → collision resistance effectively 128-bit against quantum attacks
- SHA-384 / SHA-512 → maintain adequate security
The fix for symmetric cryptography is straightforward: use AES-256 instead of AES-128, and SHA-384/512 instead of SHA-256 for sensitive applications. No algorithm replacement is needed — just a key size increase.
The CRQC Timeline
Current quantum computers (IBM, Google, IonQ, others) are NISQ (Noisy Intermediate-Scale Quantum) devices with hundreds to thousands of physical qubits, but high error rates. Running Shor's algorithm on a 2048-bit RSA key requires approximately 4,000 stable logical qubits — each logical qubit requires hundreds to thousands of physical qubits for error correction. We are at least a decade away from that scale.
However, the planning horizon for cryptographic migration in large organizations is 5–15 years. Starting now is not alarmism; it is prudent risk management for any organization handling data with long-term sensitivity.
NIST PQC Standardization: The Final Standards
In 2016, NIST launched a public competition to identify and standardize post-quantum cryptographic algorithms. Over 69 candidate algorithms were submitted from researchers worldwide. After eight years of rigorous evaluation — including cryptanalysis by the global security community and multiple rounds of selection — NIST published its final post-quantum cryptography standards in August 2024:
FIPS 203: ML-KEM (Module Lattice-based Key Encapsulation Mechanism)
Formerly known as CRYSTALS-Kyber. ML-KEM is the primary algorithm for key encapsulation — replacing the key exchange portion of TLS, SSH, and similar protocols. It is a Key Encapsulation Mechanism (KEM), not a raw key agreement protocol like ECDH.
ML-KEM-768 is the recommended default for most applications. Public keys are 1,184 bytes — much larger than a 32-byte EC point, but negligible in modern network contexts.
FIPS 204: ML-DSA (Module Lattice-based Digital Signature Algorithm)
Formerly known as CRYSTALS-Dilithium. ML-DSA replaces RSA and ECDSA for digital signatures — TLS certificate signatures, code signing, document signing, and authentication tokens. It is the primary signature algorithm in the new NIST suite due to its excellent performance/security tradeoff.
FIPS 205: SLH-DSA (Stateless Hash-based Digital Signature Algorithm)
Formerly known as SPHINCS+. SLH-DSA is a conservative backup signature algorithm based entirely on hash function security — making it resistant to attacks on lattice-based schemes. It has larger signatures (~8–50 KB depending on parameter set) and slower signing than ML-DSA, but its security assumptions are extremely well-understood. Use it as a second signature in high-assurance contexts, or as a backup if ML-DSA vulnerabilities are discovered.
FIPS 206: FN-DSA (FFT-based NTRU Digital Signature Algorithm)
Formerly known as Falcon. FN-DSA offers compact signatures (600–1,200 bytes) — smaller than ML-DSA — with strong security. However, it requires Gaussian sampling during key generation, which has historically been a source of side-channel vulnerabilities in naive implementations. Use ML-DSA as the primary signature algorithm; FN-DSA is appropriate when signature size is a critical constraint and implementations are carefully hardened.
PQC Algorithm Families: Technical Deep Dive
Lattice-Based Cryptography (ML-KEM, ML-DSA, FN-DSA)
The NIST-standardized algorithms ML-KEM and ML-DSA are based on the hardness of problems over mathematical lattices — specifically the Module Learning With Errors (MLWE) and Module Short Integer Solution (MSIS) problems. A lattice is a grid of points in n-dimensional space. The security assumption is that given a "noisy" system of linear equations over a lattice, recovering the exact solution is computationally hard even for quantum computers.
Lattice problems have been studied since the 1990s and have resisted cryptanalysis by both classical and quantum algorithms. The best known quantum attacks against MLWE are no better than classical attacks — there is no known quantum speedup analogous to Shor's algorithm for lattice problems. This is why lattice-based schemes dominate the NIST selection.
Hash-Based Cryptography (SLH-DSA)
Hash-based signatures like SLH-DSA rely only on the security of a cryptographic hash function — one of the best-understood primitives in cryptography. The signature scheme builds Merkle trees of one-time signature keys. Security holds as long as the hash function is collision-resistant and second-preimage-resistant. Since Grover's algorithm only halves the effective security of hash functions (rather than breaking them), SHA-256 at the right parameter settings remains sufficient.
Algorithm Comparison
| Algorithm | Type | Public Key Size | Sig/CT Size | Speed |
|---|---|---|---|---|
| ML-KEM-768 | KEM | 1,184 B | 1,088 B (CT) | Very Fast |
| ML-DSA-65 | Signature | 1,952 B | 3,293 B | Fast |
| FN-DSA-512 | Signature | 897 B | 666 B | Moderate |
| SLH-DSA-128s | Signature | 32 B | 7,856 B | Slow signing |
| RSA-2048 | Classical | 256 B | 256 B | Moderate |
| ECDSA P-256 | Classical | 64 B | 64 B | Very Fast |
PQC keys and signatures are larger than classical equivalents, but remain practical for virtually all network protocols. The performance overhead on modern hardware is negligible.
Migration Strategy: Becoming Quantum-Ready
Phase 1: Cryptographic Inventory (CBOM)
You cannot protect what you cannot see. Create a Cryptographic Bill of Materials (CBOM) — a complete inventory of every cryptographic algorithm, key, certificate, and protocol in use across your environment. This includes:
- All TLS certificates (public-facing and internal)
- SSH host keys and authorized user keys
- Code-signing certificates and keys
- VPN and IPsec configurations
- Database encryption keys
- Application-layer encryption (JWT signing keys, API tokens)
- Hardware Security Module (HSM) contents
- Third-party libraries and SDKs that perform cryptography
Phase 2: Risk Prioritization
Not all cryptography carries the same risk. Prioritize migration based on:
Phase 3: Crypto-Agility and Hybrid Modes
Crypto-agility means designing systems so that cryptographic algorithms can be swapped out without architectural changes. If your application hardcodes "RSA-2048" rather than abstracting the algorithm behind a configurable interface, migration will be expensive and error-prone. Refactor toward algorithm-agnostic crypto APIs.
Hybrid cryptography combines a classical algorithm with a post-quantum algorithm, providing security as long as at least one of them is secure. This is the recommended transition approach: if ML-KEM turns out to have an undiscovered flaw, ECDH still protects the session; if a quantum computer breaks ECDH, ML-KEM still protects it. TLS 1.3 RFC 8446 extensions already support hybrid key exchange with X25519+ML-KEM.
Phase 4: Upgrade Roadmap
- Update to libraries with PQC support: OpenSSL 3.5+, BouncyCastle 1.78+, liboqs (Open Quantum Safe project).
- Enable hybrid TLS on your reverse proxies and CDN (Cloudflare, AWS CloudFront support hybrid now).
- Work with your CA to obtain PQC-capable certificates as they become available.
- Migrate internal PKI roots to ML-DSA before migrating leaf certificates.
- Update SSH configurations to support post-quantum KEX when OpenSSH support matures.
- Re-encrypt archived data using AES-256 if currently using AES-128.
EP Cybertools Post-Quantum Readiness Checks
EP Cybertools includes SSL/TLS analysis tools that assess your server's current cryptographic posture and flag areas requiring attention for post-quantum readiness:
- TLS Version Detection: Verifies TLS 1.3 is enabled (a prerequisite for hybrid PQC key exchange) and flags deprecated TLS 1.0/1.1.
- Key Exchange Analysis: Identifies whether your server supports X25519 (the best current classical KEM) and whether any hybrid PQC key exchange is being offered.
- Certificate Algorithm Inspection: Shows the signature algorithm on your TLS certificate (RSA, ECDSA, or post-quantum) and key size adequacy.
- Cipher Suite Grading: Scores your cipher suite configuration against current NIST recommendations, flagging weak suites that should be disabled.
Real-World PQC Deployments
Post-quantum cryptography has moved from theory to production at scale. Here are concrete examples of organizations that have already deployed PQC:
Google deployed X25519Kyber768 hybrid key exchange in Chrome 116 (August 2023) for TLS 1.3 connections. This protects billions of HTTPS connections daily from harvest-now-decrypt-later attacks. Chrome 131 updated to use the final NIST-standardized ML-KEM in hybrid mode.
Cloudflare has supported post-quantum TLS key exchange since 2022 and updated to ML-KEM in 2024 across its global CDN edge network. All traffic through Cloudflare-proxied sites now benefits from PQC hybrid key exchange by default when the client supports it.
The NSA's Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) mandates ML-KEM and ML-DSA for all National Security Systems. CISA's guidance recommends all US critical infrastructure operators begin PQC migration planning immediately. Federal agencies have been directed to transition to PQC algorithms by 2035.
Major financial institutions including JPMorgan Chase and SWIFT have begun PQC pilot programs. The financial sector faces particular urgency due to data retention requirements — financial transaction records retained for 7–10 years are prime targets for harvest-now-decrypt-later attacks by well-resourced adversaries.
Frequently Asked Questions
Does switching to post-quantum cryptography break existing systems?
Deployed correctly, no. The recommended transition approach uses hybrid algorithms — combining a classical algorithm (like X25519) with a post-quantum algorithm (like ML-KEM). Systems that don't support the PQC component still negotiate the classical algorithm and work as before. This backward compatibility is why hybrid modes exist. Only pure post-quantum deployments (without classical fallback) could break compatibility with legacy clients.
Is AES still secure against quantum computers?
AES-256 remains secure against quantum attacks. Grover's algorithm provides a quadratic speedup for brute-force searches, which effectively halves the security bits of symmetric keys. AES-128 would drop to 64-bit effective security — insufficient. AES-256 drops to 128-bit effective security — still computationally infeasible. If you're currently using AES-128, upgrading to AES-256 is a simple, high-priority hardening step you can take right now.
What happened to CRYSTALS-Kyber — is it the same as ML-KEM?
Yes. CRYSTALS-Kyber was the name of the candidate algorithm submitted to the NIST competition. When NIST standardized it in FIPS 203, they renamed it ML-KEM (Module Lattice-based Key Encapsulation Mechanism). The underlying algorithm is the same, but NIST made minor normative changes during standardization. Similarly, CRYSTALS-Dilithium became ML-DSA, SPHINCS+ became SLH-DSA, and Falcon became FN-DSA. Early deployments by Google and Cloudflare used "Kyber" — these have since been updated to the final ML-KEM standard.
Should I wait for TLS and PKI standards to mature before migrating?
For your network perimeter (TLS), you don't need to wait — hybrid key exchange is ready to deploy via Cloudflare, nginx with OpenSSL 3.5+, or most modern reverse proxies. For your PKI and certificate infrastructure, some standards are still maturing (hybrid certificate formats, OCSP for PQC, etc.), so a wait of 1–2 years for that specific layer is reasonable. But you should absolutely start the cryptographic inventory and crypto-agility work now — that has zero interoperability risks and is prerequisite to everything else.
What is "harvest now, decrypt later" and how serious is this threat?
Harvest now, decrypt later (HNDL) — also called "store now, decrypt later" (SNDL) — describes a threat model where an adversary records encrypted network traffic today and stores it, planning to decrypt it in the future once a quantum computer is available. This threat is real and active: NSA and intelligence agencies from other nations are almost certainly already doing this. The seriousness depends on the sensitivity and shelf-life of your data. For data that must remain secret for 10+ years — classified government communications, trade secrets, long-term financial records, medical records — this threat is urgent. For session tokens that expire in hours, it's negligible.
Continue Learning
Explore more security guides and check your infrastructure with EP Cybertools.