Post-Quantum Cryptography Explained: ML-KEM, ML-DSA and How NIST’s Standards Change Your PKI

🔎 Last updated 7 Nov 2026 · Editorial policy · Report an error

On August 13, 2024, NIST finalized its first post-quantum cryptography standards—FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA)—giving the industry concrete, standardized quantum-resistant algorithms to replace RSA and elliptic-curve primitives. RSA and ECC are not broken today, and you should not rip out your PKI tomorrow. But “harvest now, decrypt later” adversaries are already recording encrypted traffic, so for data whose confidentiality must survive a decade or more, migrating key exchange to hybrid post-quantum TLS is urgent. Signature and certificate migration can follow a measured timeline—starting with a cryptographic inventory and hybrid TLS rollout now.

Why quantum computers break RSA and ECC (and why you shouldn’t panic yet)

RSA and ECC draw their security from two mathematical problems: integer factorization and the elliptic-curve discrete logarithm problem. Both fall to Shor’s algorithm, which runs in polynomial time on a sufficiently large fault-tolerant quantum computer. That is the entire threat model in one sentence—a cryptographically relevant quantum computer (CRQC) doesn’t merely weaken classical public-key cryptography; it breaks it outright.

The operative word is “sufficiently.” Breaking RSA-2048 requires, by most academic estimates, thousands of logical qubits translating into millions of physical qubits after error correction. Current machines—IBM’s Condor at 1,121 physical qubits, Google’s Willow—sit orders of magnitude short, and error-correction overhead remains the dominant unsolved engineering problem. Grover’s algorithm, by contrast, only halves the effective security of symmetric ciphers, so AES-256 remains comfortably safe. The asymmetry matters: symmetric cryptography needs modest key-size adjustments; public-key infrastructure needs replacement algorithms.

You should not panic—but you should not idle either. CISA, NSA, and NIST all position migration as a decade-scale program, not a patch cycle. A CRQC in the early 2030s is plausible enough that data with long confidentiality lifetimes encrypted today under classical key exchange is already at risk.

The three NIST standards: FIPS 203, 204 and 205 at a glance

NIST published the first finalized post-quantum cryptography standards on August 13, 2024:

• FIPS 203 — ML-KEM (Module-Lattice Key Encapsulation Mechanism): the primary quantum-resistant key-exchange mechanism, derived from the CRYSTALS-Kyber submission.
• FIPS 204 — ML-DSA (Module-Lattice Digital Signature Algorithm): the primary quantum-resistant signature scheme, from CRYSTALS-Dilithium.
• FIPS 205 — SLH-DSA (Stateless Hash-Based Digital Signature Algorithm): a conservative hash-based backup signature scheme, from SPHINCS+.

NIST deliberately excluded stateful hash-based signatures like XMSS and LMS from these FIPS—stateful schemes offer small keys and signatures but are operationally dangerous: reusing a one-time signature state catastrophically breaks security. They remain standardized elsewhere (SP 800-208) for niche uses like firmware signing, where their state management burden is controllable.

ML-KEM: lattice-based key encapsulation explained

ML-KEM’s security rests on the hardness of the Module Learning-With-Errors (MLWE) problem: distinguishing lattice points perturbed by small random noise from uniformly random data. In plain English—you encode a secret into a lattice with a pinch of noise, and recovering the secret from the noisy public artifact is believed hard even for quantum computers.

FIPS 203 defines three parameter sets:

• ML-KEM-512 — roughly AES-128 equivalent security; smallest keys (800-byte public key).
• ML-KEM-768 — roughly AES-192 equivalent; the default for TLS deployments (1,184-byte public key, 1,088-byte ciphertext).
• ML-KEM-1024 — roughly AES-256 equivalent; for the highest assurance tiers.

The encapsulation flow will feel familiar if you’ve used RSA-OAEP or ECIES: the receiver publishes a keypair’s public key; the sender encapsulates—generating a shared secret plus a ciphertext—and the receiver decapsulates the ciphertext with its private key to derive the same shared secret. In TLS 1.3, that shared secret feeds the key schedule exactly like an ECDHE output. There’s no per-message encryption like RSA; it’s pure KEM, built for key agreement.

ML-DSA and SLH-DSA: post-quantum signatures

Signatures are the harder migration, and the two standards embody a deliberate trade-off:

• ML-DSA (FIPS 204) is the workhorse. Parameter sets ML-DSA-44, -65, and -87 track Category 2/3/5 security; public keys run ~1.3–2.6 KB and signatures ~2.4–4.6 KB. Fast, lattice-based, but the “new math” bet.
• SLH-DSA (FIPS 205) is the hedge. Security reduces to the well-understood hardness of hash functions—no new assumptions. The cost: signatures balloon to ~7.8–49 KB. It’s the algorithm you deploy where signing is infrequent but trust must be maximally conservative (root CAs, firmware).

A pragmatic pattern already emerging in the CA world: SLH-DSA at the root, ML-DSA in issuing CAs and end-entity certificates. You eat the size penalty where it’s cheap (offline roots) and the speed win where it matters (high-volume issuance).

Hybrid key exchange: combining X25519 with ML-KEM

Here’s the migration logic: ML-KEM is younger mathematics than RSA or ECDH. A lattice attack, or an implementation flaw, discovered in five years would be catastrophic for anyone who migrated wholesale. Hybrid key exchange removes that bet—you run X25519 and ML-KEM, feed both shared secrets into the TLS 1.3 key schedule, and security holds as long as at least one algorithm survives.

The IETF-specified group X25519MLKEM768 (RFC-drafted hybrid for TLS 1.3) is the de facto standard. Deployment is no longer theoretical: Chrome enabled X25519MLKEM768 by default in 2024, and Cloudflare reports that a double-digit percentage of its human TLS traffic now negotiates post-quantum hybrid key exchange. Firefox followed, and Apple enabled it in iOS 26/macOS 26. OpenSSL 3.5 shipped X25519MLKEM768 natively; in Go 1.24+, it’s simply the default:

tls.Config{ } // Go 1.24+ negotiates X25519MLKEM768 automatically

For OpenSSL 3.5:

openssl s_client -connect example.com:443 -groups X25519MLKEM768

If your TLS termination stack predates these releases, the oqs-provider module from the Open Quantum Safe project brings ML-KEM and ML-DSA to OpenSSL 3.x via providers.

Hands-on: generating PQC keys and testing hybrid TLS today

With OpenSSL 3.5 or later, everything ships in the box:

# Generate an ML-KEM-768 key pair
openssl genpkey -algorithm mlkem768 -out mlkem768.key

# Inspect the negotiated group on a hybrid-enabled server
openssl s_client -connect example.com:443 -groups X25519MLKEM768 -brief

On older OpenSSL 3.x, install oqs-provider (openssl list -kem-algorithms should then list ML-KEM variants) or use the OQS oqs-openssl fork. The -brief output tells you immediately whether the handshake completed with the hybrid group—look for Negotiated TLS1.3 group: X25519MLKEM768. curl built against OpenSSL 3.5+ does the same transparently; libcurl’s CURLINFO_SSL_NEGOTIATED_GROUP-equivalent verbose output shows the group in use.

Test against hybrid-enabled endpoints (Cloudflare fronts many) before touching production: you want to catch middlebox breakage in a lab, not at 2 a.m.

How NIST’s standards change PKI: certificates, CAs and HSMs

Key exchange was the easy part because it needs no certificates. Signatures are where PKI feels the change. A traditional X.509 certificate carries one signature algorithm; pure PQC certificates swap that for ML-DSA or SLH-DSA, and every verifying party must understand the algorithm. That’s a bootstrapping problem across every browser, OS trust store, and client library.

The interim answer is composite and hybrid certificates, under active development in the IETF LAMPS working group (draft-ietf-lamps-pq-composite-sigs and related drafts). A composite certificate carries a traditional and a PQC signature simultaneously, letting validators accept either. NIST’s SP 1800-38 (NCCoE Migration to PQC) work documents exactly these patterns with vendor participation.

What CA operators must evaluate now:

• HSM support: leading vendors—Thales, Entrust, Utimaco, YubiHSM—have shipped or announced FIPS 203/204 firmware support. Verify your specific firmware version and key-generation APIs; ML-DSA keygen is not drop-in ECDSA.
• CA/Browser Forum posture: the Forum has actively discussed PQC certificate profiles; no public root program mandates PQC certificates yet, which means public trust PQC issuance is still exploratory. Private PKIs can move faster.
• Double-signing bridges: for internal PKIs, dual-issuing (same subject, parallel classical and PQC chains) avoids composite-certificate compatibility risk at the cost of operational complexity.

Migration risks for real PKI estates

The technical standards are solved; your estate is not. Recurring failure modes:

• Crypto-agility gaps: most organizations cannot answer “where is RSA/ECC used, and who owns it?” without months of discovery. This is why NIST’s own guidance starts with inventory, not algorithms.
• Larger handshakes and fragmentation: the ML-KEM-768 public key adds ~1.2 KB to the ClientHello. Combined with a hybrid certificate chain, handshakes can exceed a single TCP segment, triggering MTU issues and occasional handshake failures behind constrained middleboxes—a problem Cloudflare and Google both worked around during rollout (CERT compression and HelloRetryRequest help).
• Embedded and long-lived devices: the IoT sensor with an eight-year service life and no firmware path to ML-KEM is your real deadline. Fielded devices effectively freeze your classical algorithms in place until hardware refresh.
• Code-signing lifecycles: binaries signed today with ML-DSA need verifiers that understand ML-DSA for years. Sign-verify compatibility across OS and toolchain versions is its own migration project.
• Vendor dependency: your PQC posture is capped by your TLS load balancer, HSM, CA, and client SDK vendors’ roadmaps. Contract for it explicitly.

Harvest now, decrypt later: where post-quantum confidentiality is urgent

The Mosca inequality frames the decision: if (data confidentiality lifetime + migration time) exceeds the time until a CRQC exists, you are already exposed. Recorded TLS sessions encrypted under classical ECDHE today can be decrypted retroactively once a CRQC exists. That makes HNDL a confidentiality problem with a today deadline for:

• TLS termination at the edge — enable X25519MLKEM768 on ingress where browsers and clients support it.
• VPNs and site-to-site links — WireGuard and IPsec PQC hybrids are maturing; prioritize long-haul links carrying sensitive data.
• SSH — OpenSSH 9.0+ defaults to sntrup761x25519/mlkem768x25519-sha256 hybrids; upgrade your bastions.

Signatures and certificates do not share this urgency: a quantum computer cannot retroactively forge a signature on traffic it never had. Signature migration protects against future forgery, not past recording—so it can, and should, follow a measured CA/HSM-maturity-driven timeline.

A practical migration checklist

• Inventory first. Build a Cryptographic Bill of Materials (CBOM—the CycloneDX 1.6 standard adds a cryptography bom-ref domain) covering TLS termination, VPNs, SSH, code signing, and embedded firmware.
• Prioritize by data lifetime. Anything whose confidentiality must outlast ~2035 gets hybrid key exchange first.
• Enable hybrid TLS. X25519MLKEM768 on edge termination; upgrade OpenSSL to 3.5+ or deploy oqs-provider; verify with -brief output and monitor for handshake-failure regressions.
• Track the timeline. NIST IR 8547 proposes deprecating classical public-key algorithms by 2030 and disallowing them around 2035—work backward from those dates, and review NIST’s PQC project page and CISA’s quantum resources for updates.
• Test your vendors. HSM, CA, load balancer, and SDK—ask for FIPS 203/204 support in writing and pilot in a private PKI.
• Don’t panic on signatures. Roots and long-lived code-signing certs can move when tooling matures; key exchange cannot wait.

Frequently Asked Questions

Is RSA-2048 broken by quantum computers today?

No. Breaking RSA-2048 with Shor’s algorithm requires millions of physical qubits with full error correction; today’s largest machines have roughly a thousand noisy qubits. But harvest-now-decrypt-later attacks mean traffic recorded today can be decrypted later—which is exactly why post-quantum key exchange is worth adopting now for long-lived data.

Which NIST PQC algorithm should I use first?

Hybrid key exchange: X25519 combined with ML-KEM-768 (FIPS 203) in TLS 1.3. It delivers post-quantum confidentiality immediately while hedging against weaknesses in the newer lattice math. Signature and certificate migration (ML-DSA/SLH-DSA) can follow as CA and HSM support matures.

Do post-quantum certificates exist today?

Yes, but mainly in private PKIs and pilots. Composite and hybrid certificate formats are still in IETF LAMPS drafts, and most public CAs do not issue pure PQC certificates yet. The practical path today: test ML-DSA issuance and validation in an internal PKI.

How much bigger are PQC keys and signatures?

Significantly. An ML-KEM-768 public key is ~1,184 bytes versus 32 bytes for X25519. An ML-DSA-65 signature is ~2.4 KB versus ~64–72 bytes for ECDSA P-256. Expect larger TLS handshakes, possible fragmentation behind MTU-constrained paths, and bigger certificate chains.

What is the NIST deprecation timeline for RSA and ECC?

NIST IR 8547 proposes deprecating classical public-key algorithms (RSA, ECDSA, ECDH) around 2030 and disallowing them around 2035. Treat those as planning targets: internal PKIs should complete hybrid/PQC migration well before 2030 to leave buffer for long-lived devices.

Sources and further reading: NIST FIPS 203, NIST FIPS 204, NIST FIPS 205, the NIST Post-Quantum Cryptography project, CISA’s quantum-readiness guidance, and the Open Quantum Safe project.

{
“@context”: “https://schema.org”,
“@type”: “TechArticle”,
“headline”: “Post-Quantum Cryptography Explained: ML-KEM, ML-DSA and How NIST’s Standards Change Your PKI”,
“description”: “A practitioner’s guide to NIST’s 2024 PQC standards (FIPS 203, 204, 205): how ML-KEM, ML-DSA and SLH-DSA work, hybrid key exchange, and realistic PKI migration risks.”,
“author”: {“@type”: “Organization”, “name”: “Hmmnm – Cybersecurity Tutorials”, “url”: “https://hmmnm.com”},
“datePublished”: “2025-01-01”,
“publisher”: {“@type”: “Organization”, “name”: “Hmmnm”, “url”: “https://hmmnm.com”},
“mainEntityOfPage”: “https://hmmnm.com/post-quantum-cryptography-explained”,
“keywords”: “post-quantum cryptography, ML-KEM, ML-DSA, SLH-DSA, FIPS 203, FIPS 204, FIPS 205, hybrid key exchange, PKI migration”
}

Related reading

• Break Your Own PKI: A Hands-On Lab for Hash Collisions, Weak CSRs and Revocation Failures
• Hunt Ransomware with Velociraptor: Build Custom VQL Artifacts for LockBit-Style TTPs

Published by Hmmnm

Hands-on cybersecurity tutorials, CVE breakdowns, and guided learning paths — written and lab-tested by the Hmmnm team.

Learning Paths · About Hmmnm · Editorial policy