Skip to content

CONCEPT Cited by 3 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 patterns/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/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 (concepts/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 (patterns/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).
Last updated · 200 distilled / 1,178 read