Field Journal

Cryptography / Emerging Topics

Post-Quantum Cryptography (PQC) Migration

Post-Quantum Cryptography (PQC) prepares enterprise systems for the advent of Cryptographically Relevant Quantum Computers (CRQCs). No such machine exists yet, but a sufficiently large, fault-tolerant quantum computer running Shor's algorithm would break classical public-key cryptography (RSA, ECC, ECDSA, ECDH) in polynomial time — and given multi-year migration timelines, security architects must plan now. Execute a phased migration to finalized NIST PQC standards FIPS 203, 204 and 205, with FN-DSA/FIPS 206 under development, and track NSA CNSA 2.0 migration deadlines.

Quantum Threat Horizon: Shor’s vs Grover’s Algorithm

Quantum computing impacts symmetric and asymmetric primitives in fundamentally different ways:

Comparison of Shor's polynomial-time break of RSA and elliptic-curve cryptography with Grover's ideal quadratic query speedup against symmetric key search and hash preimages.

Shor's algorithm changes the asymptotic security of RSA and ECC; Grover's algorithm changes ideal query exponents, while concrete symmetric-attack cost still depends on the quantum implementation and resources

  1. Asymmetric Cryptography (RSA, ECC, ECDSA, ECDH): Shor’s Algorithm solves prime factorization and discrete logarithms in polynomial time — a genuine asymptotic break relative to the best-known classical attacks. Quoting one fixed exponent without defining the circuit and arithmetic model gives false precision because concrete resource estimates depend on that model. This is a contingent, not a present-tense, threat: it requires a sufficiently capable, fault-tolerant Cryptographically Relevant Quantum Computer (CRQC), and no such machine exists today. Once one does exist at sufficient scale, it would render RSA/ECC/ECDSA/ECDH’s underlying hard problems tractable.
  2. Symmetric Ciphers (AES): Grover’s Algorithm reduces ideal sequential exhaustive-search query complexity from approximately 2^n to 2^(n/2). This exponent is not a concrete practical security-strength rating: a real attack also depends on reversible-circuit depth, oracle cost, error correction, parallelization, and available quantum hardware. AES-128 remains NIST’s Category 1 comparison baseline, while AES-256 provides additional margin where a profile or long protection lifetime justifies it; Grover’s algorithm does not by itself require replacing AES.
  3. Hash Functions (SHA-256/384/512): Grover’s Algorithm gives an ideal quadratic query speedup against preimage search. Collision resistance has a different bound: it is already ~n/2 bits classically (the birthday bound), and the BHT quantum collision algorithm has an ideal query bound of roughly ~n/3 under strong quantum-memory assumptions. These exponents guide comparison, not concrete attack budgets.

Symmetric vs. Asymmetric Post-Quantum Migration Strategy

Understanding the difference between symmetric and asymmetric post-quantum security is critical for engineering roadmaps:

Cryptographic Realm Quantum Threat Algorithm Quantum Attack Impact Post-Quantum Mitigation Action
Asymmetric Cryptography (RSA, ECC, ECDSA, ECDHE) Shor’s Algorithm Solves factorization and discrete logarithms in polynomial time — a superpolynomial asymptotic improvement over the best-known classical attacks, with concrete cost depending on the quantum circuit and arithmetic model. This is only realized on a sufficiently capable, fault-tolerant CRQC, which does not exist yet, and NIST cautions that concrete quantum security estimates are more nuanced than a simple asymptotic comparison. Must migrate to new PQC algorithms (FIPS 203 ML-KEM for key exchange, FIPS 204 ML-DSA for signatures), prioritized by each system’s confidentiality lifetime and risk (see above).
Symmetric Ciphers (AES, ChaCha20) Grover’s Algorithm Ideal sequential key-search queries fall from approximately 2^n to 2^(n/2); concrete cost also depends on the quantum circuit and resources. Keep standardized symmetric algorithms and select key size from the governing profile, protection lifetime, and desired margin. AES-128 remains NIST’s Category 1 comparison baseline; AES-256 supplies additional margin rather than satisfying a universal doubling mandate.
Hash Functions (SHA-256/384/512 — no key, so “key size” doesn’t apply) Grover’s Algorithm (preimage); BHT (collision) Ideal query bounds are approximately 2^(n/2) for preimages and 2^(n/3) for BHT collisions, under their respective models; neither is a concrete wall-clock estimate. Select digest size from the required property and applicable profile. Larger digests provide additional margin, but do not convert the ideal query exponent directly into a practical security-strength guarantee.
PQC Migration Context
Why PQC Migration is Required for Network Protocols

Network protocols such as TLS 1.3 use a key-establishment result and the handshake transcript as inputs to HKDF, which derives negotiated traffic secrets, keys, and IVs; they do not distribute a pre-existing AES-256 session key. If a future CRQC breaks a recorded session's classical key-establishment component, the adversary may reconstruct the shared secret and derive that session's traffic secrets and keys, regardless of whether its negotiated AEAD was AES-128-GCM, AES-256-GCM, ChaCha20-Poly1305, or another permitted choice. Deploying Post-Quantum Key Encapsulation (FIPS 203 ML-KEM), typically in a hybrid group alongside classical ECDHE, protects against that specific harvest-now-decrypt-later exposure — how quickly a given system needs to do so depends on its confidentiality lifetime, threat horizon, protocol and library support, and any applicable regulatory profile, not a blanket deployment rule for every system.

The “Harvest Now, Decrypt Later” Attack Threat

Adversaries may be collecting and storing encrypted high-value enterprise traffic today (“Harvest Now, Decrypt Later”). If a suitable CRQC becomes available in the future, recorded traffic encrypted under classical RSA or ECDHE key exchanges could be decrypted retroactively.

Harvest Now, Decrypt Later Mitigation
Migration Urgency Scales With Data Confidentiality Lifetime

This is a risk-based, not a one-size-fits-all, decision: compare your data's required confidentiality lifetime against your organization's CRQC-arrival estimate and remaining migration lead time. Systems protecting data with long confidentiality lifetimes (commonly cited as 5+ years, though the right threshold depends on which CRQC-timeline estimate you plan against) should prioritize deploying hybrid post-quantum key exchange (X25519MLKEM768) soonest to reduce exposure to retroactive decryption of harvested traffic; systems handling only short-lived data can migrate on a longer timeline without immediate risk from harvest-now-decrypt-later.

Finalized NIST PQC Standards and FIPS 206 Under Development

On August 13, 2024, NIST officially published the finalized Federal Information Processing Standards (FIPS) for Post-Quantum Cryptography: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA). NIST is developing a fourth standard, FIPS 206, for FN-DSA (Falcon); it is not yet a finalized FIPS publication, so deployment status must be tracked through NIST’s PQC project:

Finalized PQC Standards (August 2024)

FIPS Standard Algorithm Name Mathematical Paradigm Target Function Status & Primary Engineering Role
FIPS 203 ML-KEM (Kyber) Module Lattice (ML-WE) Key Encapsulation Mechanism (KEM) FINALIZED (Aug 2024): ML-KEM encapsulation takes the recipient’s encapsulation key and produces both a ciphertext and a newly established shared secret; decapsulation uses the corresponding decapsulation key and ciphertext to recover that secret (NIST FIPS 203). It is not RSA-OAEP-style direct message encryption and does not wrap a caller-supplied symmetric key. A protocol or KEM/DEM construction passes the shared secret through a KDF and uses the derived keying material with an AEAD.
FIPS 204 ML-DSA (Dilithium) Module Lattice (ML-SIS) General Digital Signatures FINALIZED (Aug 2024): Primary standard for general-purpose digital signatures and PKI (NIST FIPS 204).
FIPS 205 SLH-DSA (SPHINCS+) Stateless Hash Trees Backup Digital Signatures FINALIZED (Aug 2024): Purely hash-based signature scheme providing conservative fallback safety (NIST FIPS 205).

Standard Under Development

Planned Standard Algorithm Name Mathematical Paradigm Target Function Status & Primary Engineering Role
FIPS 206 (in development) FN-DSA (Falcon) Fast-Fourier Lattice Compact Digital Signatures UNDER DEVELOPMENT: NIST is preparing the FN-DSA standard; no final FIPS 206 has been published.

Backup KEM: HQC

In March 2025, NIST selected HQC (Hamming Quasi-Cyclic) as a fifth PQC algorithm, intended as a structurally independent backup to ML-KEM. Where ML-KEM’s security rests on module-lattice problems, HQC is code-based — built on error-correcting codes rather than lattices — so a future cryptanalytic advance against lattice problems would not automatically compromise HQC as well. NIST has not yet finalized an HQC FIPS standard; a draft is expected to work through the standard NIST public-review process. Treat HQC as a diversification hedge for the KEM layer rather than a near-term deployment target until a finalized standard exists.

NSA CNSA 2.0 Timeline & Transition Strategy (National Security Systems)

For U.S. National Security Systems (NSS) subject to Commercial National Security Algorithm Suite 2.0 (NSA CNSA 2.0) guidance, the NSA outlines target adoption and exclusive-use timelines:

Hybrid Cryptography Transition Pattern

Hybrid key establishment combines classical and post-quantum inputs so that a failure in one family does not automatically expose the derived secret. Production transition designs include TLS 1.3 X25519MLKEM768, OpenSSH’s sntrup761x25519-sha512 exchange, and Signal’s PQXDH protocol:

Shared Secret S = KDF(Classical_ECDH_Secret || PostQuantum_KEM_Secret)

In TLS 1.3, the IETF has defined the X25519MLKEM768 hybrid group (IANA codepoint 0x11EC, combining classical Curve25519 ECDH with FIPS 203 ML-KEM-768) in RFC 10024, “Post-Quantum Traditional (PQ/T) Hybrid Key Agreement Mechanisms for TLS 1.3” — published as a Proposed Standard on August 10, 2026. The same document also defines SecP256r1MLKEM768 and SecP384r1MLKEM1024 as related hybrid groups; X25519MLKEM768 is the one marked “Recommended.”

The hybrid formula above is intentionally simplified: production hybrid combiners bind more than the two raw secrets. X25519MLKEM768’s actual construction concatenates the ML-KEM shared secret and the X25519 shared secret in a fixed order (PQC secret first) as input to TLS 1.3’s existing HKDF pipeline. This fixed ordering is protocol-defined and matters for interoperability and for matching the applicable compliance construction — implementations on both ends must agree on the exact byte layout being fed into HKDF, or the derived keys won’t match at all. These two properties are separate and shouldn’t be conflated: the shared secrets (ML-KEM’s and X25519’s raw outputs) are inputs to the TLS key schedule, concatenated and fed through HKDF — they aren’t themselves transcript messages. The transmitted key shares (the client’s ML-KEM encapsulation key and X25519 share, and the server’s ML-KEM ciphertext and X25519 share) are what actually appear in the handshake messages, and those messages are what’s covered and authenticated by the handshake transcript (per the mechanics described on the TLS Handshake page).

Crypto Agility & PQC Migration: Engineering Practicalities

Migrating a real system is a program of work, not a library upgrade. Several practical constraints determine how long that program actually takes:

What I need to remember

FIPS 203/204/205 are finalized post-quantum standards; a cryptographically relevant quantum computer capable of running Shor's algorithm against RSA/ECC doesn't exist yet, but harvest-now-decrypt-later risk means long-lived confidential data needs hybrid PQC migration planning now. CNSA 2.0's stricter timeline applies specifically to U.S. National Security Systems, not systems generally.

Primary references