Skip to content

CONCEPT Cited by 9 sources

Post-quantum cryptography

Definition

Post-quantum cryptography (PQC) is the class of cryptographic primitives designed to resist cryptanalytic attack by a sufficiently powerful quantum computer. "Sufficiently powerful" is a cryptographically- relevant quantum computer (CRQC) — one capable of running Shor's algorithm on key sizes in deployed use, which would break RSA, classical Diffie-Hellman, and elliptic-curve-based key-agreement / signature schemes.

PQC is not a replacement for symmetric cryptography (AES, SHA-2) — those are weakened by Grover's algorithm only by a square-root factor, mitigated by doubling key sizes. PQC specifically replaces the asymmetric primitives: key-encapsulation mechanisms (KEMs) and digital signatures.

Two-axis threat model (2026 update)

As of the 2026 Q-Day reassessment, PQC deployment is driven by two distinct, orthogonal threats with different time profiles:

Axis Threat Primitive Urgency driver
Confidentiality HNDL — adversary captures ciphertext now, decrypts post-Q-Day PQ KEM (e.g. ML-KEM, Streamlined NTRU Prime) Set by session-data lifetime, not Q-Day date
Authentication Active impersonation — adversary with a CRQC forges signatures, MITMs, derives long-term keys PQ signatures (e.g. ML-DSA, SLH-DSA) Set by Q-Day date — signatures cannot be retroactively forged

Industry practice through 2024 focused on axis 1 (KEMs) because HNDL was the dominant threat and forging past signatures is impossible. The 2026 priority flip (Google / Cloudflare / IBM Quantum Safe consensus) makes axis 2 (authentication) the new urgent front now that Q-Day is near enough that active-CRQC attacks must be planned for.

Store-now-decrypt-later (HNDL)

The motivating threat model for KEM-side deployment: the adversary records encrypted traffic today and decrypts it years later once a CRQC exists. Any protocol that uses classical asymmetric key- agreement for session-key derivation is vulnerable to this retroactive attack.

An attacker could save encrypted sessions now and, if a suitable quantum computer is built in the future, decrypt them later. This is known as a "store now, decrypt later" attack. (Source: sources/2025-09-15-github-post-quantum-security-for-ssh-access-on-github)

The implication: the KEM deployment schedule is set by session lifetime, not by when CRQCs arrive. If captured traffic today will still be sensitive in 2040, and a CRQC could arrive between now and 2040, then PQ KEM needs to be rolled out now — regardless of whether the CRQC materializes on schedule. This is why deployments have started a decade before any realistic CRQC.

KEM vs signature

Two distinct deployment tracks:

  • Key-encapsulation mechanisms (KEMs) — replace classical DH / ECDH for session-key agreement. Protect the confidentiality of transport. Examples: ML-KEM (NIST FIPS 203, formerly Kyber), Streamlined NTRU Prime.
  • Post-quantum signatures — replace RSA/ECDSA/Ed25519 for authenticity. Protect against impersonation attacks. Examples: ML-DSA (NIST FIPS 204, formerly Dilithium), SLH-DSA (FIPS 205, SPHINCS+).

KEM rollout proceeded faster in practice because the store-now- decrypt-later threat is only a KEM problem — an attacker can't retroactively forge signatures over past traffic. Signature rollout is driven by impersonation risk, which is live-attack rather than historic-capture — so in the far-Q-Day regime there was less time pressure. That calculus inverts near Q-Day: see concepts/post-quantum-authentication.

Canonical PQ-KEM primitives in deployed protocols

Both are typically deployed in hybrid construction with a classical primitive.

Canonical PQ-signature primitives

  • ML-DSA (Dilithium) — NIST FIPS 204, lattice-based, general-purpose PQ signature. Cloudflare's Mid-2026 Cloudflare→origin deployment target.
  • SLH-DSA (SPHINCS+) — NIST FIPS 205, hash-based, conservative security assumptions; larger signatures but simpler cryptanalytic surface. Suited for long-lived / rare-signing keys (firmware, roots).
  • Falcon — NIST FIPS 206-draft, lattice-based with smaller signatures than ML-DSA but more complex implementation.

Cost of early deployment

PQ KEMs have larger public keys, ciphertexts, and shared secrets than classical ECDH. Streamlined NTRU Prime sntrup761:

Primitive Public key Ciphertext
X25519 (classical) 32 bytes 32 bytes
sntrup761 1158 bytes 1039 bytes

Hybrid adds the two together on the wire. Per-handshake CPU cost is modest on modern hardware but measurable. For high-connection-rate services (SSH at a hyperscaler's scale), the aggregate impact is real and worth monitoring through rollout.

PQ signatures are even more size-heavy:

Primitive Public key Signature
Ed25519 (classical) 32 B 64 B
ML-DSA-65 ~1.95 kB ~3.3 kB
SLH-DSA ~32 B 8-49 kB

For TLS certificate chains (leaf + intermediates), the signature- size explosion is load-bearing for protocol design. See Merkle Tree Certificates for the batch-and-amortise response.

Less battle-tested than classical

"These post-quantum algorithms are newer and thus have received less testing" — a standard caveat during early PQ deployment. The hybrid construction exists specifically to defend against this: a later-discovered flaw in the PQ primitive leaves the classical half still protecting confidentiality against classical adversaries.

This is why "PQ-only" deployments are typically not recommended during the transition window — the hybrid is strictly safer on both axes (PQ-capable against quantum, classical-strong against classical) until the PQ primitive has enough cryptanalytic scrutiny.

The same logic applies on the signature side — hybrid signatures (classical + PQ, both must verify) are the mainstream transition shape during 2026-2029.

Non-breaking rollout via algorithm negotiation

PQC rollout into an installed base — SSH, TLS, IPsec — exploits the fact that all three protocols have built-in algorithm negotiation. Servers add the PQ hybrid to their supported-algorithm list; clients that also support it auto-select; clients that don't fall back to classical. No flag day, no coordinated client upgrade. (Source: sources/2025-09-15-github-post-quantum-security-for-ssh-access-on-github)

But adding PQ to the negotiation is not the whole migration — under near-Q-Day threat, classical must also be disabled or downgrade attacks defeat the rollout. See disable-legacy-before-rotate for the full three- step sequence (enable PQ → disable classical → rotate all secrets that ever crossed classical sessions).

The 2026 roadmap landmark

Cloudflare's 2026-04-07 post is the canonical wiki landmark on the updated threat assessment:

  • >65 % of human traffic to Cloudflare is already PQ-encrypted (KEM side, 2022 rollout).
  • Cloudflare targets 2029 for full PQ security including authentication.
  • Intermediate milestones: Mid-2026 PQ auth for Cloudflare→origin (ML-DSA); Mid-2027 PQ auth for visitor→Cloudflare (MTC); Early 2028 Cloudflare One PQ-secure; 2029 full product suite.
  • Default-on, no additional cost posture — consistent with 2014 Universal SSL + 2022 PQ-for-all.

(Source: sources/2026-04-07-cloudflare-targets-2029-for-full-post-quantum-security)

Seen in

  • sources/2026-09-08-cloudflare-automatic-key-exchange-faster-post-quantum-secure-origin-han — PQ KEM deployment made automatic on TLS origin connections. Cloudflare's Automatic Key Exchange probes each origin and leads with the PQ hybrid X25519MLKEM768 wherever supported, taking PQ origin traffic to 45B connections/day and PQ-in-1-RTT from 0% to 99.2% — the confidentiality (KEM) axis, deployed by default with no operator action. Adds a new intent-based compliance control (PQ-hybrid-only and/or FIPS-only negotiation).
  • sources/2026-04-30-cloudflare-post-quantum-encryption-for-cloudflare-ipsec-is-ga — canonical site-to-site / IPsec instance. Cloudflare's 2026-04-30 GA of hybrid ML-KEM for Cloudflare IPsec per draft-ietf-ipsecme-ikev2-mlkem. First canonical wiki instance of PQ KEM deployment in enterprise site-to-site networking. Extends the KEM-side rollout shape from TLS (2022) and SSH (2025) into IPsec, four years behind TLS — Cloudflare attributes the delay to the IPsec community's continued QKD interest (RFC 8784, 2020) and to ciphersuite bloat from RFC 9370 shipping as extension-mechanism-without-named-default. Branch- connector interoperability verified with Cisco 8000 Series 26.1.1+ and Fortinet FortiOS 7.6.6+; Palo Alto Networks currently non-interop (canonical ciphersuite-bloat case study). Post-quantum authentication for IPsec is the remaining gap Cloudflare flags for future IETF work. Canonical instance of the TLS-first PQC rollout as blueprint pattern and the third instance of default-on security upgrade at no additional cost after 2014 Universal SSL + 2022 TLS PQ.
  • sources/2025-09-15-github-post-quantum-security-for-ssh-access-on-github — GitHub rolls out sntrup761x25519-sha512 on SSH endpoints for github.com and non-US GHEC regions. Store-now-decrypt-later cited as the motivating threat. US region carved out for FIPS (fips-cryptographic-boundary) until FIPS-approved PQ primitives (ML-KEM) are supported by the underlying SSH library. KEM-side rollout — the canonical instance of the 2022-era "deploy PQ KEM by default via algorithm negotiation" pattern.
  • sources/2026-04-07-cloudflare-targets-2029-for-full-post-quantum-security — Cloudflare publishes an accelerated 2029 full-PQ-security roadmap: PQ encryption done (>65 % of human traffic, 2022 rollout), authentication now the urgent threat. Mid-2026 ML-DSA for Cloudflare→origin; Mid-2027 Merkle Tree Certificates for visitor→Cloudflare; Early 2028 Cloudflare One SASE; 2029 fully PQ secure. Articulates the two-axis threat model (HNDL vs authentication), the priority flip, the add-PQ-is-not-enough / disable-legacy-before-rotate / third-party-dependency disciplines, and the default-on-no-extra-cost posture. The authentication-side canonical wiki instance complementing the GitHub KEM-side instance.
  • sources/2026-03-31-google-safeguarding-cryptocurrency-by-disclosing-quantum-vulnerabilities-responsibly — producer-side companion to the Cloudflare post. Google Research's responsible-disclosure methodology for the new quantum attack on ECDLP-256 that drives the 2026 Q-Day reassessment. Extends classical coordinated disclosure to trust-sensitive substrates (cryptocurrency) by adding ZKP-based substantiation (zkp-capability-disclosure) + scope clarification + defensive-progress highlighting. Canonical wiki framing for how pre-Q-Day cryptographic breakthroughs can be disclosed without either helping adversaries (full disclosure) or denying defenders the signal to accelerate migration (no disclosure).
  • sources/2024-12-02-meta-built-large-scale-cryptographic-monitoring — fleet-inventory producer for PQC migration. Meta's 2024 cryptographic-monitoring architecture (FBCrypto + aggregating buffered logger + Scribe + Scuba/Hive) is the operational prerequisite for knowing where in the fleet classical asymmetric primitives are in use — without which migration prioritisation is guesswork. Meta ties this explicitly to PQC: "More recently, this is aiding our efforts to ensure post- quantum readiness in our asymmetric use cases. The available data improves our decision-making process while prioritizing quantum-vulnerable use cases." Canonical wiki instance of the inventory-before-migration discipline for PQC at hyperscale, complementing the rollout-shape instances (GitHub / Cloudflare) and the disclosure instance (Google).
  • sources/2026-04-16-meta-post-quantum-cryptography-migration-at-meta-framework-lesson — migration-framework companion to the 2024-12-02 Meta monitoring post. Meta publishes the PQC Migration Levels ladder (PQ-Unaware → PQ-Aware → PQ-Ready → PQ-Hardened → PQ-Enabled) organised around time to react to a relevant quantum event, the three-tier prioritisation framework (offline-attack / online-attack / Grover-only), the

two-mechanism crypto-inventory approach, explicit external dependencies (standards / hardware / implementations), the PQC guardrails playbook (updated guidelines + key-generation friction + build-system API rules in Buck), and the hybrid-over- replacement deployment decision with SIKE's 2022 invalidation cited as precedent. Meta's cryptographers are co-authors of HQC (NIST-selected 2025 as non-lattice diversity hedge) + BIKE + Classical McEliece. Meta is a Linux Foundation PQCA member and contributes to LibOQS. No production deployment numbers disclosed. Canonical wiki instance of the migration-strategy-framework discipline for PQC at hyperscale; complements the inventory-side (2024-12-02 Meta monitoring) + rollout-shape (GitHub / Cloudflare) + disclosure (Google) instances with the governance + program-management angle.

  • concepts/post-quantum-cryptography — the dominant KEM-side deployment shape during the transition window.
  • patterns/protocol-algorithm-negotiation — the non-breaking enablement rollout mechanism.
  • fips-cryptographic-boundary — why rollout isn't uniform across regulated and unregulated environments.
  • concepts/digital-sovereignty — broader framing for why regional crypto surface differs.
  • concepts/q-day — the operational-threshold framing driving deployment urgency.
  • concepts/q-day — the adversary capability PQC defends against.
  • concepts/harvest-now-decrypt-later — the historical primary threat driving KEM-side rollout.
  • concepts/post-quantum-authentication — the newly-urgent signature-side migration.
  • concepts/downgrade-attack — why adding PQ is not sufficient.
  • long-lived-key-risk — the migration-priority input for scarce-CRQC conditions.
  • concepts/zero-knowledge-proof — the responsible-disclosure channel Google used for its 2026 algorithmic breakthrough.
  • concepts/coordinated-disclosure — the baseline disclosure norm the 2026 Google quantum disclosure extends to trust- sensitive substrates.
  • concepts/threat-modeling — the disclosure-side attack axis the 2026 Google ZKP-based disclosure defends against.
  • zkp-capability-disclosure — the pattern realising the Google 2026 responsible-disclosure methodology.
  • disable-legacy-before-rotate — the three-step migration discipline.
  • third-party-dependency-quantum-assessment — scope expansion to indirect vendors.
  • patterns/default-on-security-upgrade — the Cloudflare strategic framing for PQ-for-all.
  • systems/ml-dsa-signature — canonical PQ signature primitive.
  • systems/merkle-tree-certificates — PQ-size-aware certificate issuance system.
  • systems/pq-hsts — browser-side downgrade-protection mechanism.
  • systems/certificate-transparency — sibling downgrade- protection / audit mechanism.
  • concepts/post-quantum-cryptography — the five-rung maturity ladder (PQ-Unaware → PQ-Enabled).
  • pqc-prioritization-framework — the three-tier attack-class prioritisation taxonomy.
  • concepts/q-day — the urgency metric organising the migration ladder.
  • concepts/post-quantum-cryptography — the deployment-path decision axis.
  • crypto-inventory — the prerequisite discipline underneath all PQC migration work.
  • pqc-migration-ladder — the programme-management pattern for laddered migration commitments.
  • crypto-api-guardrails — the three-layer prevent-new-vulnerable-usages pattern.
  • automated-discovery-plus-developer-reporting — the complementary two-mechanism inventory pattern.
  • systems/ml-kem — canonical PQ KEM (FIPS 203).
  • systems/hqc — non-lattice PQ KEM selected by NIST 2025.
  • systems/liboqs — open-source reference implementation library.
  • concepts/post-quantum-cryptography — ability to swap algorithms without re-architecture; absent from EO 14409.
  • cryptographic-bill-of-materials — exhaustive crypto inventory; Cloudflare argues against as prerequisite for action.
  • quantum-impact-inventory — risk-first alternative to CBOM.
  • supply-chain-pressure — federal procurement as PQC adoption forcing function.
  • tunnel-first-inventory-later — immediate HNDL protection without waiting for per-system audit.
  • encryption-before-authentication-sequencing — deploy KEMs before signatures due to differing threat timelines.
  • supply-chain-pressure-for-adoption — contractor mandate cascading PQC to all customers.

Federal mandate (EO 14409, June 2026)

Executive Order 14409 (signed June 22, 2026) sets binding deadlines for federal PQC migration:

Deadline Requirement
Dec 2030 HVAs and high-impact systems → PQ key establishment (ML-KEM)
Dec 2031 HVAs and high-impact systems → PQ digital signatures (ML-DSA/SLH-DSA)
Dec 2030 Federal contractors → NIST PQC FIPS compliance

The EO explicitly excludes QKD, endorsing only algorithm-based PQC. National Security Systems are on a separate classified track (NSA, 2030-2033).

Key deployment data point: two-thirds of browser traffic to Cloudflare is already protected with PQ encryption (X25519MLKEM768 hybrid) as of June 2026, demonstrating encryption-side migration is production-viable at internet scale.

Open questions flagged by Cloudflare's analysis: - What does "transition" mean? (support? prefer? disable-classical?) - concepts/post-quantum-cryptography is not mandated. - The one-year gap between encryption (2030) and authentication (2031) deadlines is tight given the authentication dependency chain; concurrent work is required.

(Source: sources/2026-06-23-cloudflare-post-quantum-eo-milestone)

NIST signatures on-ramp (2026 landscape update)

As of July 2026, NIST advanced nine candidate post-quantum signature algorithms to the third round of the "signatures on-ramp" competition. These are the next generation beyond ML-DSA — designed to improve on its wire sizes — but none will be available in time for the first PQ migration (2029–2031 deadlines):

Family Candidate(s) Key strength Key weakness Est. availability
Isogeny SQIsign Near-classical sizes (148 B sig) Extremely slow signing; complex ~2035
Lattice FN-DSA 666 B sig; fast verification Floating-point side-channel; missing middle security ~2033
Lattice HAWK Fast signing; no FPU dependency Security assumption (LIP) under active attack ~2034
Multivariate MAYO Flexible security levels; stable design Still needs another NIST round ~2034
Multivariate SNOVA Smallest PK+sig combined Repeatedly broken and restructured uncertain
Multivariate QR-UOV/UOV Tiny signatures (96 B for UOV) Enormous public keys (66 kB+) ~2034
Proof-of-knowledge FAEST/MQOM/SDitH Conservative security; enables anonymous credentials Larger sigs than ML-DSA; slower ~2031

The central conclusion: ML-DSA is the only algorithm that will be widely deployed before the PQ deadlines arrive. The search for better algorithms matters for second-generation migration and for enabling new cryptographic capabilities (anonymous credentials, blind signatures) that ML-DSA cannot provide.

(Source: sources/2026-07-09-cloudflare-post-quantum-signature-algorithms)

Merged aliases

  • pqc-migration-levels- crypto-agility
  • hybrid-key-encapsulation
  • lattice-based-cryptography
Last updated · 766 distilled / 2,225 read