Post-Quantum Cryptography in Practice

The uncomfortable truth about post-quantum cryptography is that the migration is not a future problem — the threat to long-lived confidential data is present right now, and the standards you need to start deploying have been final since August 2024. The equally uncomfortable counter-truth is that the hype machine has dramatically overstated how urgent this is for most of the systems most infrastructure engineers actually run. The gap between “state actors are almost certainly harvesting encrypted traffic today” and “you need to replace your TLS certificates by next quarter” is wide, and it pays to understand exactly where your systems sit in that gap.

This post is the guide I wish existed when I started working through what a real migration looks like: what the math actually says breaks (and what it does not), what the three finalized NIST standards provide and for what purpose, where the first practical deployments already are (your TLS connections to Cloudflare and your OpenSSH sessions may already be quantum-resistant at the key-exchange layer without you doing anything), and what the multi-year migration roadmap looks like if you are building it with real operational constraints.

Why Quantum Computers Break Public-Key Crypto

The entire security of asymmetric cryptography — RSA, Diffie-Hellman, elliptic-curve variants — rests on mathematical problems that classical computers cannot solve in polynomial time. RSA relies on the difficulty of factoring large integers. Elliptic-curve Diffie-Hellman (ECDH) and ECDSA rely on the elliptic-curve discrete logarithm problem. Classic finite-field DH relies on the discrete logarithm in a prime field. These are all structurally different problems, but they share a fatal property: Peter Shor’s 1994 algorithm solves all of them efficiently on a quantum computer.

Shor’s algorithm runs in polynomial time, specifically O((log N)^3) for integer factorization. On a sufficiently large fault-tolerant quantum computer, a 2048-bit RSA key falls in hours. A P-256 ECDH key pair falls even faster — elliptic-curve operations require fewer qubits for the same effective attack. The entire zoo of asymmetric primitives your infrastructure relies on — TLS handshake key agreement, SSH host keys and client keys, VPN IKE key exchange, certificate signatures, code signing — all of it uses either RSA or elliptic curves in some form, and all of it is vulnerable to Shor’s algorithm.

Symmetric cryptography is a different story. Grover’s algorithm provides a quantum speedup for searching unstructured spaces, which translates to roughly halving the effective bit security of symmetric keys and hash functions. AES-128 drops to roughly 64-bit equivalent security under Grover; AES-256 drops to 128-bit equivalent. The fix is straightforward: use AES-256 and SHA-384 or SHA-512 where you are not already, and you are done. No algorithm replacement needed. This is the reason the post-quantum migration is fundamentally about replacing public-key primitives, not symmetric ones.

The critical caveat is the word “sufficiently large.” Current quantum computers are small, noisy, and cannot run Shor’s algorithm against cryptographic key sizes. IBM’s Heron processors, Google’s Willow chip — these are research instruments. The consensus estimate for a cryptographically-relevant quantum computer (CRQC) capable of attacking real-world RSA-2048 keys is somewhere in the 2030–2035 range, though estimates vary and classification-level intelligence assessments are not public. Nobody knows the true timeline. But that uncertainty is exactly why the harvest-now-decrypt-later problem is real today.

Harvest Now, Decrypt Later Is Not Theoretical

The HNDL threat model is straightforward: an adversary intercepts and stores encrypted traffic now, then decrypts it later when a CRQC becomes available. The intelligence value does not need to survive decades — it needs to survive until Q-Day, which is measured in years, not generations. Classified communications, diplomatic cables, long-term R&D data, genomic databases, and intellectual property with competitive lifetimes measured in years are the priority targets.

The UK NCSC noted explicitly in its 2023 Annual Review that state actors are conducting data theft campaigns “for exploitation in years to come.” This is not hypothetical. Nation-state signals intelligence programs have the infrastructure to collect encrypted traffic at scale, the storage to retain it indefinitely, and the motivation to wait. The entities most credibly positioned to build a CRQC are the same entities running large-scale passive collection programs.

HNDL Timeline: Why Key Establishment Migrates First

TODAY (2026)                    Q-DAY (~2030-2035?)
─────────────────────────────────────────────────────────────────────►
│                                │
│  Adversary intercepts and      │  CRQC breaks stored session keys
│  stores your TLS session       │  ──────────────────────────────►
│  (classical ECDH key exchange) │  All stored traffic now readable
│                                │
│  Data confidentiality          │  Data still confidential
│  requirement extends           │  requirement = already exposed
│  beyond Q-Day?                 │
│  │                             │
│  └─ YES: Act now on key        │
│         exchange               │
│                                │
│  Signature is already          │  Forged signatures only matter
│  verified or rejected          │  going forward — less urgent
│  at connection time            │  for existing deployments

The asymmetry here is the reason the migration order is: key establishment first, then signatures. A session key negotiated today with classical ECDH can be retroactively compromised if stored. A signature verified today is already verified — an adversary cannot retroactively un-verify it. Signatures matter more for future-dated forgery concerns (code signing, certificate trust), but that threat has a different urgency profile.

This is where the migration hits most infrastructure teams directly. Any system carrying data whose confidentiality must be maintained past approximately 2030 should have its key-exchange layer migrated now, or at minimum in the next 12–18 months. The specific systems: TLS termination for sensitive internal APIs, VPN tunnels carrying restricted data, SSH into systems that handle long-lived secrets, and any protocol that negotiates a session key over an asymmetric exchange.

The Finalized NIST Standards

NIST completed an eight-year standardization process and released three final post-quantum cryptography standards in August 2024. A fourth (FN-DSA) is still in draft review. These are not research algorithms — they are the actual standards infrastructure teams should be deploying.

ML-KEM (FIPS 203)

ML-KEM is the workhorse for key establishment. It is a Key Encapsulation Mechanism, not a raw key agreement protocol — the sender uses the recipient’s public key to encapsulate a randomly-generated shared secret, producing a ciphertext the recipient decapsulates with their private key. It is not a drop-in replacement for Diffie-Hellman at the protocol level, but the KEM abstraction maps cleanly onto TLS key exchange, SSH kex, and most VPN key agreement protocols.

Three parameter sets exist. ML-KEM-512 targets NIST security level 1 (roughly AES-128 equivalent). ML-KEM-768 targets level 3 (AES-192 equivalent). ML-KEM-1024 targets level 5 (AES-256 equivalent). For most deployments, ML-KEM-768 is the right choice — it is what OpenSSH uses in its default mlkem768x25519-sha256 kex and what TLS’s X25519MLKEM768 hybrid group uses. NSA CNSA 2.0 mandates ML-KEM-1024 for classified systems.

Performance is genuinely good. ML-KEM-768 encapsulation and decapsulation benchmark well under a millisecond on modern server hardware — faster than RSA-2048 key operations by a significant margin. This is not a performance regression.

ML-DSA (FIPS 204)

ML-DSA is the primary signature standard. Based on the Dilithium algorithm, it uses module lattice mathematics and is designed for general-purpose signing: TLS certificates, code signing, SSH host key proofs, JWT/token signing. It is fast — ML-DSA-65 signing runs 100–200 microseconds on modern hardware, faster than RSA signing.

The problem is signature size. ML-DSA-65 signatures are 3,309 bytes versus ECDSA P-256’s 64 bytes. That is a 50x size increase. For a TLS handshake, this means the Certificate and CertificateVerify messages grow substantially. If you are running a service where the TLS handshake is a meaningful fraction of the total response size — think HTTPS APIs with small JSON payloads — this hits you harder. For most web traffic and internal service calls, it is a nuisance, not a blocker.

Three parameter sets: ML-DSA-44 (level 2), ML-DSA-65 (level 3), ML-DSA-87 (level 5). CNSA 2.0 specifies ML-DSA-87 for classified systems.

SLH-DSA (FIPS 205)

SLH-DSA is the conservative backup. It does not use lattice mathematics — it is based on hash function security alone, which is the most conservative possible foundation. If the lattice hardness assumptions underlying ML-KEM and ML-DSA ever prove weaker than expected, SLH-DSA remains secure as long as SHA-256 or SHA-3 holds.

The cost is signature size. SLH-DSA signatures range from roughly 8 KB to 50 KB depending on parameter set and whether you prioritize speed or small signatures. This rules it out for high-throughput signing and TLS certificates, but it is entirely appropriate for code signing where you sign once and verify many times, or for root CA certificate signatures where size is irrelevant to the human operator. It is the belt to ML-DSA’s suspenders.

FN-DSA (FIPS 206, still in draft)

FN-DSA is based on Falcon, an NTRU lattice signature scheme. Its advantage is small signatures — roughly 666 bytes for FN-DSA-512, compared to ML-DSA-65’s 3,309 bytes. NIST submitted the initial public draft for review in August 2025; the final standard is expected in late 2026 or 2027. Do not build production systems around it yet, but watch this space — it will matter for protocols where ML-DSA’s signature bloat is a real operational constraint.

Hybrid Key Exchange: What Is Already Deployed

The engineering answer to the HNDL problem for key establishment is hybrid key exchange: combine a classical ECDH with a post-quantum KEM such that an adversary must break both to recover the session key. If ML-KEM turns out to have an undiscovered weakness, classical X25519 still provides the security you have today. If X25519 falls to a CRQC, ML-KEM protects you. You only lose if both break simultaneously, which is an extremely conservative security posture.

TLS 1.3 Hybrid Key Exchange: X25519MLKEM768

Client                                          Server
──────                                          ──────
  │                                               │
  │  ClientHello                                  │
  │  key_share: X25519 pubkey (32 B)              │
  │           + ML-KEM-768 pubkey (1184 B)        │
  │──────────────────────────────────────────────►│
  │                                               │
  │  ServerHello                                  │
  │  key_share: X25519 shared secret (32 B)       │
  │           + ML-KEM-768 ciphertext (1088 B)    │
  │◄──────────────────────────────────────────────│
  │                                               │
  │  Both sides compute:                          │
  │  session_secret = KDF(X25519_secret ||        │
  │                       MLKEM768_shared_secret) │
  │                                               │
  │  [Encrypted handshake continues]              │
  │──────────────────────────────────────────────►│

This is X25519MLKEM768, standardized in IETF draft draft-ietf-tls-ecdhe-mlkem. It is already deployed at scale. Chrome added support in version 131 (November 2024). Firefox followed in version 135 (February 2025). OpenSSL 3.5 (April 2025, LTS until 2030) ships ML-KEM support and defaults to X25519MLKEM768 as the first key share in TLS 1.3. Cloudflare enabled it by default across their network; as of early 2026, over 57% of browser-initiated connections to Cloudflare include an X25519MLKEM768 key share.

The practical implication: if you are terminating TLS at a reverse proxy or load balancer built on a recent OpenSSL, and your clients are running modern browsers or Go/Rust TLS stacks, you are probably already doing hybrid PQ key exchange without any configuration change. Verify this — do not assume — but the ecosystem has moved faster than most security teams’ migration timelines.

For explicit configuration, an Nginx server compiled against OpenSSL 3.5+ can advertise X25519MLKEM768 first:

1
2
3

# nginx.conf — require OpenSSL 3.5+ compiled in
ssl_protocols TLSv1.3;
ssl_conf_command Groups X25519MLKEM768:X25519:prime256v1;

To check what groups your OpenSSL build exposes:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

# List available TLS groups including PQ hybrids
openssl list -tls-groups 2>/dev/null | grep -i mlkem

# Check the default key share your client sends
openssl s_client -connect example.com:443 \
  -groups X25519MLKEM768:X25519 \
  -tlsextdebug 2>&1 | grep -A2 "key share"

# Quick KEM speed benchmark
openssl speed ml-kem-768 2>/dev/null

# Compare against classical operations
openssl speed ecdhx25519 rsa3072

For TLS and certificate fundamentals, the hybrid approach is transparent at the application layer — the session key derivation is internal to the TLS stack.

OpenSSH and Post-Quantum Key Exchange

OpenSSH has offered post-quantum key agreement since version 9.0 (April 2022), initially via sntrup761x25519-sha512 — a hybrid using NTRU Prime and X25519. OpenSSH 10.0 (April 2025) promoted mlkem768x25519-sha256 to the default key exchange algorithm, standardized via IETF draft-ietf-sshm-mlkem-hybrid-kex. OpenSSH 10.1 will warn when a non-PQ kex is negotiated.

This is already shipping in the OpenSSH bundled with most major Linux distributions updated to their 2025 release trees. For infrastructure engineers who follow the guidance in SSH hardening for modern infrastructure, the kex upgrade costs nothing — it works by default when both client and server run OpenSSH 10.0 or later.

To explicitly configure and verify:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# /etc/ssh/sshd_config — prefer PQ hybrid, fall back gracefully
KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512@openssh.com,curve25519-sha256,curve25519-sha256@libssh.org

# Client ~/.ssh/config — same preference order
Host *
    KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512@openssh.com,curve25519-sha256

# Verify what kex was negotiated after connecting
ssh -vvv user@host 2>&1 | grep "kex:"

# List all kex algorithms your sshd supports
sshd -T | grep kexalgorithms

Note what this does not protect: SSH host key authentication and user public key authentication still use classical algorithms (Ed25519, ECDSA, RSA). The quantum resistance here is only at the session key exchange layer — the right layer for HNDL protection, because session keys are what you are protecting against retroactive decryption. Host key authentication uses signatures that are verified in real-time; that threat profile does not require urgency today, though PQ-capable host keys will matter eventually.

The Cryptographic Inventory: Where You Actually Use Public-Key Crypto

Before you can prioritize the migration, you need to know what you have. Most organizations have never done a comprehensive cryptographic inventory, and the first time they try, they are surprised by what they find. The categories to audit:

Key establishment (highest HNDL urgency):

• TLS termination — load balancers, reverse proxies, ingress controllers
• VPN tunnels — IPsec IKEv2 key agreement, WireGuard static key bootstrapping
• SSH session key exchange (covered above)
• HTTPS API clients in application code (JDK TLS stack, Python requests/urllib3, Go’s crypto/tls)
• Database TLS connections and LDAPS/LDAP-StartTLS

Signatures (lower urgency, larger migration effort):

• TLS certificates — leaf, intermediate, root CA
• Code signing — binaries, container images, artifacts, firmware
• SSH host keys and user keys
• JWT signing keys
• S/MIME and document signing
• PKI infrastructure — the Vault PKI engine running your internal CA hierarchy
• mTLS client certificates — see mTLS for service identity

For each system, the key question is not “is this vulnerable to a CRQC?” (everything using RSA or ECC is). The question is: does the confidentiality of data protected by this key need to survive past approximately 2030–2033? If the answer is yes, the key-establishment layer of that system is a near-term priority. If the answer is no — for example, a microservice TLS connection carrying ephemeral API responses that have no long-term value — the urgency is much lower.

Migration Roadmap: Realistic Timelines

The NSA CNSA 2.0 framework provides the clearest external mandate structure for US government and defense contractors, but it is a useful reference for commercial organizations too:

For commercial infrastructure, the practical migration order is:

Phase 1 (now–18 months): Key exchange hybrid layer

This is the highest-value, lowest-disruption step. Upgrade your TLS termination layer to OpenSSL 3.5. Upgrade your OpenSSH versions. Verify that hybrid kex is negotiating by default. Check that your internal HTTP clients (Go, Java, Python, Node.js) are using TLS library versions that support X25519MLKEM768. For IPsec VPNs, check whether your vendor’s IKEv2 implementation supports hybrid PQ key agreement — StrongSwan 6.x and newer versions of commercial VPN appliances are adding this.

Phase 2 (12–36 months): Certificate infrastructure and signatures

This is harder because it requires replacing certs across your entire PKI. The size implications are real: an ML-DSA-65 signature in a TLS certificate adds ~3 KB to the handshake. On its own that is tolerable. A full certificate chain with PQ signatures at every level — leaf, intermediate, root — can add 10–15 KB to the TLS ClientHello and Certificate flight. On constrained networks, over high-latency links, or in protocols where certificates are sent in a single UDP datagram (DTLS, QUIC), this matters more.

The industry consensus right now is to keep classical ECDSA certificates for TLS and deploy hybrid key exchange — you get HNDL protection for key establishment, which is the urgent case, without the cert size headache that comes with PQ signatures. PQ certificate deployment will follow as tooling matures and CA/B Forum ballot processes update the Baseline Requirements.

Phase 3 (3–7 years): Code signing, PKI root trust, protocol-level migration

Root CA key rollovers are decade-scale events. Software supply chain signing involves trust anchors in browser stores and OS trust stores that change slowly by design. Hardware HSMs need firmware updates or replacement to support PQ key types. This is the long tail.

Crypto-Agility: The Real Engineering Goal

The migration teaches a more general lesson: your systems should not have cryptographic algorithms hardcoded in ways that require code changes and redeploys to swap. The goal of crypto-agility is the ability to negotiate, configure, and rotate cryptographic primitives without architectural changes.

Concretely: TLS already provides algorithm negotiation via cipher suites and key share extensions — the X25519MLKEM768 deployment works precisely because TLS was designed to be agile. The failure modes are in application code that hardcodes "RSA" in a key generation call, internal PKI that assumes ECDSA throughout, configuration management that never parameterizes the signature algorithm, and HSM procurement that did not ask about PQC roadmaps.

The checklist for crypto-agility: algorithm selection is configuration, not code; certificate issuance uses a pluggable signing backend (Vault, certd, EJBCA) so you can change signing algorithms at the CA layer; libraries are kept current and regularly audited against a maintained SBOM; cipher suite preferences are centrally managed rather than set per-service.

Honest Operational Realities

What is not urgent for most teams. If your threat model does not include nation-state-level passive collection of encrypted traffic, and your data has no long-term confidentiality requirement, the migration urgency is low. A typical e-commerce site handling user sessions that expire in hours has negligible HNDL exposure. An internal dashboard serving ephemeral metrics is fine with classical ECDH until ecosystem defaults upgrade it automatically. The threat model matters.

Library and tooling maturity in 2026. OpenSSL 3.5 is solid, but it is a 2025 LTS release — many distributions are still shipping 3.0 or 3.3. Java 23+ has ML-KEM support via JEP 452 (still in preview for some configurations). Go’s x/crypto module added mlkem768x25519-sha256 SSH kex support but it is not yet in the stdlib. BoringSSL (Chrome, Android) and AWS-LC (Amazon’s fork) have good ML-KEM support. LibreSSL lags. Embedded TLS libraries (mbedTLS, WolfSSL) have varying support. The ecosystem is not uniform; check your specific stack.

Key and signature sizes are a real operational concern. The numbers:

For TLS, the hybrid key share in the ClientHello roughly doubles the size of the key material extension. This is a one-time per-handshake cost that disappears into session resumption on subsequent connections. It matters most for protocols with very small MTUs or where connection establishment is the dominant cost. For most server workloads it is in the noise.

Performance is not the problem. ML-KEM operations are fast — well under a millisecond per operation on server-grade hardware, faster than RSA by a substantial margin. CPU is not the reason to delay.

HSMs and hardware tokens are the long pole. If your PKI root CA key lives in an HSM, that HSM needs firmware support for ML-KEM and ML-DSA key types before you can issue PQ certificates from it. Most HSM vendors have roadmaps but not all have shipped firmware. Smart cards and hardware tokens for code signing are similarly gated on vendor timelines. Budget for hardware refresh cycles.

Conclusion

The post-quantum migration is real but it is also structured. The most urgent layer — key establishment — is largely solved at the library and protocol level, and significant parts of it may already be deployed in your infrastructure if you are running recent software. The hybrid approach (classical ECDH plus ML-KEM, so you need to break both to compromise the session key) gives you the HNDL protection you need without betting everything on a new cryptographic family that has only been public for about a decade.

The signature migration is harder, slower, and less urgent for most commercial deployments. The size increase in ML-DSA signatures is real and will require careful handling at the certificate and protocol level. The ecosystem is catching up, but the CA/B Forum, browser trust stores, and certificate tooling all move on multi-year cycles that are largely outside your direct control. Prepare the infrastructure and tooling, but do not block on completing the signature migration before finishing the key-exchange migration.

The honest verdict on urgency: if you handle data whose confidentiality must survive past 2030, start the inventory and key-exchange migration now. If you support US government or defense contracts, CNSA 2.0 compliance timelines are non-negotiable. For everyone else, upgrading to OpenSSL 3.5, verifying hybrid kex negotiation is working, and building crypto-agility into your PKI and library upgrade practices is the right posture for 2026. The migration has started. Get ahead of it at the key-exchange layer, build the inventory now, and plan the certificate and signing infrastructure migration for the next 24–36 months.

Sources

• NIST Releases First 3 Finalized Post-Quantum Encryption Standards (NIST, August 2024)
• FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA) Finalized — Cloud Security Alliance
• State of the post-quantum Internet in 2025 — Cloudflare Blog
• Post-quantum cryptography (PQC) — Cloudflare SSL/TLS docs
• Automatically Secure: upgrading 6,000,000 domains for the Quantum Future — Cloudflare Blog
• draft-ietf-tls-ecdhe-mlkem — Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3 (IETF Datatracker)
• draft-ietf-sshm-mlkem-hybrid-kex — PQ/T Hybrid Key Exchange with ML-KEM in SSH (IETF Datatracker)
• OpenSSH: Post-Quantum Cryptography
• OpenSSH 10.0 Introduces Default Post-Quantum Key Exchange Algorithm — Quantum Computing Report
• CNSA 2.0 Explained: PQC Requirements, Timelines, and Federal Impact — QuSecure
• Harvest now, decrypt later — Wikipedia
• Harvest Now, Decrypt Later: The Threat That Is Already in Motion — Quantum Security Defence
• Quantum-Ready FN-DSA (FIPS 206) Nears Draft Approval from NIST — DigiCert
• OpenSSL 3.5 Post-Quantum Lab: ML-KEM and ML-DSA on RHEL 9.6 — Cryptomathic
• Post-Quantum Cryptography in Kubernetes — Kubernetes Blog
• NIST Post-Quantum Cryptography Standards: Complete Guide to FIPS 203, 204, 205 — QRAMM