Post-Quantum Cryptography

A sufficiently large, fault-tolerant quantum computer would break the asymmetric cryptography — RSA, Diffie-Hellman, ECDH, ECDSA — that essentially all current TLS, PKI, VPN, SSH, and code-signing infrastructure relies on. This isn't a distant, speculative concern to defer: "harvest now, decrypt later" means an adversary capturing and storing encrypted traffic today can decrypt it retroactively the moment a cryptographically-relevant quantum computer (CRQC) exists — which means data with a long confidentiality shelf-life is already at risk, regardless of how many years away a CRQC actually is. This article covers the quantum threat model, the NIST-standardized post-quantum algorithms, practical migration guidance, and the regulatory timelines now driving urgency.

This article builds on, and assumes, the classical algorithm guidance in Encryption — it covers what changes under the quantum threat and why, not a restatement of general encryption practice.

The Quantum Threat Model

Shor's Algorithm — Breaking Asymmetric Cryptography

Shor's algorithm efficiently solves integer factorization and the discrete logarithm problem on a sufficiently large quantum computer — the exact mathematical hardness assumptions that RSA, Diffie-Hellman, ECDH, and ECDSA all rely on. A CRQC running Shor's algorithm doesn't weaken these algorithms incrementally the way faster classical hardware does; it breaks them outright. This affects nearly every public-key use case in production today: TLS key exchange, PKI/certificate signatures, code signing, VPN key exchange, and SSH host and user keys.

Grover's Algorithm — Weakening Symmetric Cryptography

Grover's algorithm gives a quadratic speedup for brute-force search, which roughly halves the effective security bits of symmetric ciphers and hash functions rather than breaking them outright. AES-128 is reduced to an effective ~64-bit security level under Grover — inadequate — which is why the Encryption article's existing recommendation of AES-256 as the standing default is the correct mitigation here too: AES-256 still provides an effective ~128-bit security level even against a quantum adversary. The same halving applies to hash function preimage resistance (SHA-256 → effective ~128-bit), which remains adequate but is part of why longer hash outputs are preferred for long-lived, high-assurance signatures.

"Harvest Now, Decrypt Later" (HNDL)

This is the actual driver of migration urgency — not "when will a CRQC exist," but how long your data needs to stay confidential, plus how long migration takes. If data encrypted today needs to remain confidential for N more years, and your organisation's realistic migration timeline is M years, you needed to start migrating (N + M) years before a CRQC exists — not after. State secrets, medical and genomic records, long-lived intellectual property, and legal/financial records with decades-long confidentiality requirements are exposed today under HNDL even though no CRQC is known to exist yet.

NIST Post-Quantum Cryptography Standards

Why Multiple Algorithms and Mathematical Foundations

This isn't redundancy for its own sake — it's a deliberate hedge. Lattice-based algorithms (ML-KEM, ML-DSA, FN-DSA) are efficient and are the default choice for most deployments, but as a relatively newer hardness assumption they've had less cumulative cryptanalytic scrutiny than decades-old classical algorithms. Hash-based SLH-DSA rests on the security of hash functions themselves — extremely conservative and well-understood, at the cost of much larger signatures. Code-based HQC provides a structurally unrelated hard problem specifically so that a future cryptanalytic advance against lattices doesn't leave the standardized portfolio with a single point of failure. Don't standardize on a single mathematical foundation for your most critical systems where an alternative is practical.

Hybrid and Composite Cryptography (Migration-Era Best Practice)

The recommended near-term deployment pattern is hybrid key exchange: combine a classical algorithm (X25519/ECDH) with a PQC KEM (ML-KEM) such that the combined scheme remains secure as long as either algorithm is unbroken. This is precisely because PQC algorithms are new relative to the decades of cryptanalysis classical algorithms have withstood — hybrid mode means a flaw discovered in ML-KEM doesn't undo your security, and neither does a quantum break of X25519.

This is not theoretical — X25519+ML-KEM-768 hybrid key exchange is already deployed in production by major browsers and services (Chrome, Cloudflare, and Google have supported hybrid post-quantum TLS key exchange in production since 2023–2024). For signatures, an equivalent interim pattern is composite/hybrid certificates — a certificate carrying both a classical and a PQC signature — while CA and client ecosystem support for pure PQC certificate chains matures.

Migration Timeline and Regulatory Drivers

Practical implication: even organisations with no direct federal or national-security regulatory obligation should treat these as the de facto industry baseline — CA, browser, cloud provider, and protocol library support is being built to these deadlines regardless of any individual organisation's own compliance scope, and vendor deprecation of classical-only code paths will follow the same timeline.

Building a Migration Plan

1. Cryptographic inventory first. You cannot migrate what you haven't catalogued. Build a full inventory of every place classical public-key cryptography is used — TLS endpoints, VPN and SSH keys, PKI/CA hierarchies, code and firmware signing, embedded/IoT device certificates, document signing, and HSM-backed keys used for key wrapping. Consider maintaining this as a Cryptographic Bill of Materials (CBOM) — the same discipline as the SBOM practice covered in SAST and SCA, applied to cryptographic assets instead of software dependencies.
2. Prioritise by data sensitivity and shelf-life, applying the HNDL math above — a system protecting data that must stay confidential for 20 years is a higher near-term priority than one protecting data with a one-year shelf-life, independent of any regulatory deadline category.
3. Prioritise by migration difficulty and blast radius next. PKI root/intermediate CA hierarchies and firmware/embedded-device signing have the longest lead times — hardware refresh cycles, embedded fleets that can't be remotely re-keyed, and CA chain re-issuance lead times — start these earliest, not last.
4. Adopt hybrid modes as the default posture during the transition, not pure PQC-only, for the algorithmic-diversity hedge described above.
5. Track actual vendor and library support, not just standard availability. Confirm your TLS stack, cloud KMS, and CA/PKI vendor genuinely support ML-KEM/ML-DSA in the specific product and version you run before committing to a migration date.
6. Re-test performance and size assumptions. PQC keys, ciphertexts, and signatures are meaningfully larger than their classical equivalents (see the table below) — this can affect TLS handshake fragmentation behaviour, embedded-device memory/flash constraints, and size assumptions baked into legacy protocol implementations.
7. Plan for crypto-agility. Design systems so the next algorithm swap doesn't require a full re-architecture — this will not be the last cryptographic transition your systems go through.

Size and Performance Comparison

Post-quantum algorithms are not drop-in replacements from a size perspective — this is one of the most common sources of migration surprises (protocol fragmentation, embedded device constraints, storage assumptions):

The "s" (small/slow) SLH-DSA parameter sets favour a smaller signature at the cost of slower signing; "f" (fast) variants exist with the reverse tradeoff. Choose based on which resource — bandwidth/storage or CPU time — is actually constrained in your deployment.

Migration Checklist

References

• Encryption
• SAST and SCA
• NIST FIPS 203 — Module-Lattice-Based Key-Encapsulation Mechanism Standard
• NIST FIPS 204 — Module-Lattice-Based Digital Signature Standard
• NIST FIPS 205 — Stateless Hash-Based Digital Signature Standard
• NIST IR 8547 — Transition to Post-Quantum Cryptography Standards
• Executive Order 14412 — Securing the Nation Against Advanced Cryptographic Attacks
• NSA Commercial National Security Algorithm Suite 2.0 (CNSA 2.0)
• NIST Post-Quantum Cryptography Project