Post-Quantum Cryptography: The Complete Guide to ML-KEM, ML-DSA, and Beyond

Quantum computers won’t just make encryption slower — they’ll break it entirely. Shor’s algorithm, running on a sufficiently powerful quantum computer, can factor large integers and solve discrete logarithms in polynomial time, completely breaking RSA, Diffie-Hellman, and elliptic curve cryptography (ECC). This isn’t theoretical: 57% of industry leaders believe a cryptographically relevant quantum computer will exist within 3 years¹.

The good news? NIST has already standardized post-quantum alternatives. In 2024, NIST released FIPS 203 (ML-KEM/Kyber), FIPS 204 (ML-DSA/Dilithium), and FIPS 205 (SLH-DSA/SPHINCS+), with FIPS 206 (FN-DSA/FALCON) in final review. These algorithms are designed to resist both classical and quantum attacks.

This guide explains how post-quantum cryptography works, compares the four major algorithms, and shows you how to start migrating today using hybrid mode — combining classical algorithms (RSA/ECC) with post-quantum ones for defense-in-depth.

Want to experiment with post-quantum cryptography right now? Try the ML-KEM Key Encapsulation and ML-DSA Sign/Verify tools — both run entirely in your browser.

The Quantum Threat: Why RSA and ECC Are Doomed

Shor’s Algorithm: The Cryptography Killer

Shor’s algorithm (1994) solves two mathematical problems that classical cryptography relies on:

1. Integer factorization — Breaking RSA by factoring the modulus n = p × q
2. Discrete logarithm — Breaking Diffie-Hellman and ECC by solving for the private key

A classical computer would need millions of years to factor a 2048-bit RSA key. A large-scale quantum computer running Shor’s algorithm could do it in hours.

Grover’s Algorithm: The Symmetric Threat

Grover’s algorithm (1996) speeds up brute-force searches, effectively halving the security of symmetric encryption:

• AES-128 → 64-bit security (breakable)
• AES-256 → 128-bit security (still secure)

This is why AES-256 is considered quantum-resistant, but RSA-2048 and ECC-256 are not.

“Harvest Now, Decrypt Later” Attacks

Here’s the urgent part: adversaries are already stockpiling encrypted data today — diplomatic cables, financial records, intelligence reports — waiting for the day quantum computers can decrypt it. This is called “Harvest Now, Decrypt Later” (HNDL).

If your data must remain secret for 10+ years, you need to migrate to post-quantum cryptography now, before quantum computers arrive. Waiting until “Q-Day” (the day quantum computers break RSA/ECC) is too late.

When Is Q-Day?

Estimates vary, but most experts predict a cryptographically relevant quantum computer (capable of breaking RSA-2048) will exist between 2030 and 2040. The Global Risk Institute estimates a >50% probability within 15 years².

But remember: if your data needs to stay secret for 20 years, and migration takes 5 years, and Q-Day is in 15 years — you’re already behind schedule.

What Is Lattice-Based Cryptography?

Three of the four NIST post-quantum algorithms (ML-KEM, ML-DSA, FN-DSA) are based on lattice problems. Let’s demystify what that means.

The Intuition: Finding the Closest Point

Imagine a grid of points in 2D space (like graph paper). Now imagine someone gives you a point that’s close to one of the grid points, but not exactly on it. Your job: find the closest grid point.

In 2D, this is trivial. But in 1000-dimensional space with a carefully constructed lattice, this becomes computationally hard — even for quantum computers.

This is the Shortest Vector Problem (SVP) and Closest Vector Problem (CVP), the mathematical foundation of lattice-based cryptography.

Why Lattices?

Lattice problems have three properties that make them ideal for cryptography:

1. Quantum resistance — No known quantum algorithm solves lattice problems efficiently
2. Provable security — Security can be reduced to worst-case hardness of lattice problems (strong theoretical foundation)
3. Efficiency — Lattice operations are fast and produce relatively small keys/signatures

Module-LWE: The Specific Problem

ML-KEM and ML-DSA are based on Module Learning With Errors (Module-LWE), a specific lattice problem:

The problem: Given a matrix A and a vector b = A·s + e (where s is a secret vector and e is small random “error”), find s.

Without the error e, this is just linear algebra (easy). With small error, it becomes computationally hard — and the hardness holds even for quantum computers.

Don’t worry if the math seems abstract. The key takeaway: lattice problems are hard for both classical and quantum computers, making them the foundation of post-quantum cryptography.

The Four NIST Post-Quantum Standards

ML-KEM (CRYSTALS-Kyber) — Key Encapsulation

FIPS 203 (August 2024)

ML-KEM is designed for key encapsulation — securely exchanging symmetric keys over insecure channels. It replaces RSA key exchange and (EC)DHE in TLS, SSH, and other protocols.

How it works:

1. Alice generates a public/private key pair using Module-LWE
2. Alice sends her public key to Bob
3. Bob generates a random symmetric key (e.g., AES-256) and “encapsulates” it using Alice’s public key, producing a ciphertext
4. Bob sends the ciphertext to Alice
5. Alice “decapsulates” the ciphertext using her private key to recover the symmetric key
6. Both now share the same symmetric key for encrypted communication

Security levels:

• ML-KEM-512 — ~128-bit security (AES-128 equivalent)
• ML-KEM-768 — ~192-bit security
• ML-KEM-1024 — ~256-bit security (AES-256 equivalent)

Key sizes:

• Public key: 800-1568 bytes (vs 32 bytes for ECC-256, 256 bytes for RSA-2048)
• Private key: 1632-3168 bytes
• Ciphertext: 768-1568 bytes

Performance:

• Key generation: ~0.2ms (ML-KEM-768)
• Encapsulation: ~0.3ms
• Decapsulation: ~0.3ms

Use when: You need quantum-resistant key exchange for TLS, SSH, VPNs, or secure messaging. ML-KEM is the primary algorithm for general-purpose encryption.

ML-DSA (CRYSTALS-Dilithium) — Digital Signatures

FIPS 204 (August 2024)

ML-DSA is the primary post-quantum digital signature algorithm. It replaces RSA signatures, ECDSA, and Ed25519.

How it works:

1. Signer generates a public/private key pair using Module-LWE
2. To sign a message, signer computes a hash of the message, then uses the private key to produce a signature
3. Anyone with the public key can verify the signature proves the signer held the private key and the message hasn’t been altered

Security levels:

• ML-DSA-44 — ~128-bit security
• ML-DSA-65 — ~192-bit security
• ML-DSA-87 — ~256-bit security

Key sizes:

• Public key: 1312-2592 bytes
• Private key: 2560-4896 bytes
• Signature: 2420-4627 bytes

Performance:

• Key generation: ~0.5ms (ML-DSA-65)
• Signing: ~1.5ms
• Verification: ~2.0ms

Use when: You need quantum-resistant digital signatures for code signing, document signing, TLS certificates, or blockchain. ML-DSA is the primary algorithm for signatures.

SLH-DSA (SPHINCS+) — Hash-Based Signatures (Backup)

FIPS 205 (August 2024)

SLH-DSA is a stateless hash-based signature scheme, serving as a conservative backup if lattice-based algorithms (ML-DSA) are ever broken.

How it works: Unlike lattice-based algorithms, SLH-DSA relies only on the security of hash functions (SHA-256 or SHAKE256). It uses a complex tree structure of one-time signatures (Winternitz OTS) and hypertrees to enable stateless signing.

Security levels:

• SLH-DSA-SHA2-128s — ~128-bit security (SHA-256 based, small signatures)
• SLH-DSA-SHA2-192s — ~192-bit security
• SLH-DSA-SHA2-256s — ~256-bit security
• SLH-DSA-SHAKE-128s — ~128-bit security (SHAKE256 based)

Key sizes:

• Public key: 32-64 bytes (much smaller than ML-DSA!)
• Private key: 64-128 bytes
• Signature: 7856-49856 bytes (much larger than ML-DSA)

Performance:

• Key generation: ~0.01ms (very fast)
• Signing: ~0.5-3.0 seconds (very slow!)
• Verification: ~0.01-0.1ms (fast)

Use when: You need a conservative backup signature algorithm with minimal trust assumptions (only hash function security). SLH-DSA is slower but mathematically simpler than lattice-based alternatives.

FN-DSA (FALCON) — Compact Lattice Signatures

Draft FIPS 206 (in final review, expected 2025)

FN-DSA is another lattice-based signature algorithm, designed for smaller signatures than ML-DSA.

How it works: FN-DSA uses NTRU lattices (a specific type of lattice) and Fast Fourier Transform (FFT) over lattices to produce compact signatures.

Security levels:

• FN-DSA-512 — ~128-bit security
• FN-DSA-1024 — ~256-bit security

Key sizes:

• Public key: 897-1793 bytes
• Private key: 1280-2304 bytes
• Signature: 666-1280 bytes (much smaller than ML-DSA!)

Performance:

• Key generation: ~1-5ms
• Signing: ~5-20ms
• Verification: ~1-5ms

Use when: You need compact signatures for bandwidth-constrained applications (IoT, mobile, blockchain). FN-DSA signatures are 3-5× smaller than ML-DSA, but the algorithm is newer and less battle-tested.

Algorithm Comparison Table

Property	ML-KEM-768	ML-DSA-65	SLH-DSA-SHA2-128s	FN-DSA-512
Type	Key encapsulation	Digital signature	Digital signature	Digital signature
Basis	Module-LWE	Module-LWE	Hash-based (SHA-256)	NTRU lattice
Security level	~192 bits	~192 bits	~128 bits	~128 bits
Public key size	1184 bytes	1952 bytes	32 bytes	897 bytes
Private key size	2400 bytes	4032 bytes	64 bytes	1280 bytes
Signature/Ciphertext size	1088 bytes	3309 bytes	17088 bytes	666 bytes
Key generation speed	~0.2ms	~0.5ms	~0.01ms	~2ms
Sign/Encaps speed	~0.3ms	~1.5ms	~0.5s	~10ms
Verify/Decaps speed	~0.3ms	~2.0ms	~0.05ms	~3ms
NIST standard	FIPS 203 (2024)	FIPS 204 (2024)	FIPS 205 (2024)	FIPS 206 (draft)
Primary use	TLS key exchange	Code signing, certificates	Backup signatures	Compact signatures
Quantum resistant	✅ Yes	✅ Yes	✅ Yes	✅ Yes

Key takeaways:

• ML-KEM is for key exchange (replaces RSA/ECDHE)
• ML-DSA is the primary signature algorithm (replaces RSA/ECDSA/Ed25519)
• SLH-DSA is the conservative backup (hash-based, minimal assumptions)
• FN-DSA is for compact signatures (3-5× smaller than ML-DSA)

Hybrid Mode: The Migration Strategy

You can’t switch to post-quantum cryptography overnight. Legacy systems still require RSA/ECC, and PQC algorithms haven’t been battle-tested for decades yet. The solution: hybrid mode.

What Is Hybrid Mode?

Hybrid mode combines a classical algorithm (RSA or ECC) with a post-quantum algorithm (ML-KEM or ML-DSA). Both algorithms must be broken for the system to be compromised.

For key exchange:

• Classical: X25519 (ECDH on Curve25519)
• Post-quantum: ML-KEM-768
• Hybrid: X25519 + ML-KEM-768 (both key exchanges happen, secrets are combined)

For signatures:

• Classical: Ed25519 or ECDSA P-256
• Post-quantum: ML-DSA-65
• Hybrid: Ed25519 + ML-DSA-65 (both signatures are created and verified)

Why Hybrid Mode?

1. Defense in depth — If the PQC algorithm has a hidden vulnerability, the classical algorithm still protects you. If quantum computers arrive, the PQC algorithm protects you.

2. Backward compatibility — Systems that don’t support PQC can still use the classical algorithm. Systems that do support PQC get quantum resistance.

3. Gradual migration — You can deploy hybrid mode today, then remove the classical algorithm once PQC is fully trusted.

Real-World Adoption

Hybrid mode is already deployed in major protocols:

• TLS 1.3 — Chrome, Firefox, and Cloudflare support X25519 + ML-KEM-768 hybrid key exchange
• Signal — Uses X25519 + ML-KEM-768 for key exchange (since 2023)
• OpenSSH — Supports [email protected] hybrid key exchange
• Apple iMessage — Uses PQXDH (Post-Quantum Extended Diffie-Hellman) with X25519 + ML-KEM-768

Code Examples

Browser — Web Crypto API (ML-KEM-768)

// Note: Web Crypto API support for ML-KEM is experimental as of 2026
// This example uses the proposed API

// Generate an ML-KEM-768 key pair
const keyPair = await crypto.subtle.generateKey(
  { name: 'ML-KEM', parameter: 'ML-KEM-768' },
  true,
  ['encapsulate', 'decapsulate']
);

// Encapsulate a shared secret (sender)
const { ciphertext, sharedSecret: senderSecret } = await crypto.subtle.encapsulate(
  { name: 'ML-KEM' },
  keyPair.publicKey
);

// Decapsulate the shared secret (receiver)
const receiverSecret = await crypto.subtle.decapsulate(
  { name: 'ML-KEM' },
  ciphertext,
  keyPair.privateKey
);

// Both parties now have the same shared secret (32 bytes)
// Use it as a symmetric key for AES-GCM
console.log('Sender secret:', new Uint8Array(senderSecret));
console.log('Receiver secret:', new Uint8Array(receiverSecret));

Browser — Web Crypto API (ML-DSA-65)

// Generate an ML-DSA-65 key pair
const keyPair = await crypto.subtle.generateKey(
  { name: 'ML-DSA', parameter: 'ML-DSA-65' },
  true,
  ['sign', 'verify']
);

// Sign a message
const message = new TextEncoder().encode('Hello, post-quantum world!');
const signature = await crypto.subtle.sign(
  { name: 'ML-DSA' },
  keyPair.privateKey,
  message
);

// Verify the signature
const isValid = await crypto.subtle.verify(
  { name: 'ML-DSA' },
  keyPair.publicKey,
  signature,
  message
);

console.log('Signature valid:', isValid);
console.log('Signature size:', signature.byteLength, 'bytes'); // ~3309 bytes

Python — pqcrypto library (ML-KEM-768)

from pqcrypto.kem.mlkem768 import generate_keypair, encapsulate, decapsulate

# Generate key pair
public_key, secret_key = generate_keypair()

# Encapsulate (sender)
shared_secret_sender, ciphertext = encapsulate(public_key)

# Decapsulate (receiver)
shared_secret_receiver = decapsulate(ciphertext, secret_key)

# Both parties now have the same 32-byte shared secret
assert shared_secret_sender == shared_secret_receiver
print(f"Shared secret: {shared_secret_sender.hex()}")
print(f"Ciphertext size: {len(ciphertext)} bytes")  # 1088 bytes

Python — pqcrypto library (ML-DSA-65)

from pqcrypto.sign.mldsa65 import generate_keypair, sign, verify

# Generate key pair
public_key, secret_key = generate_keypair()

# Sign a message
message = b"Hello, post-quantum world!"
signature = sign(message, secret_key)

# Verify the signature
is_valid = verify(message, signature, public_key)
print(f"Signature valid: {is_valid}")
print(f"Signature size: {len(signature)} bytes")  # 3309 bytes
print(f"Public key size: {len(public_key)} bytes")  # 1952 bytes

OpenSSL CLI (Hybrid Key Exchange: X25519 + ML-KEM-768)

# OpenSSL 3.2+ supports post-quantum algorithms

# Generate a hybrid X25519 + ML-KEM-768 key pair
openssl genpkey -algorithm X25519-ML-KEM-768 -out hybrid_key.pem

# Extract the public key
openssl pkey -in hybrid_key.pem -pubout -out hybrid_pub.pem

# Use in TLS 1.3 (server configuration)
# openssl s_server -key hybrid_key.pem -cert server.crt \
#   -named_curves X25519-ML-KEM-768

# Sign a document with ML-DSA-65
openssl dgst -sha256 -sign mldsa64_private.pem \
  -out signature.bin document.pdf

# Verify the signature
openssl dgst -sha256 -verify mldsa64_public.pem \
  -signature signature.bin document.pdf

Our ML-KEM Key Encapsulation and ML-DSA Sign/Verify tools let you experiment with these algorithms directly in your browser — no installation required.

Security Considerations

• Post-quantum algorithms are new. ML-KEM and ML-DSA were standardized in 2024, after 6+ years of public cryptanalysis. While no attacks have been found, they haven’t been battle-tested for decades like RSA or ECC. Use hybrid mode to maintain classical security as a fallback.

• Key sizes are large. ML-KEM-768 public keys are 1184 bytes (vs 32 bytes for X25519). ML-DSA-65 signatures are 3309 bytes (vs 64 bytes for Ed25519). This impacts bandwidth, storage, and certificate sizes. Plan accordingly for high-throughput or constrained environments.

• Implementation matters. Side-channel attacks (timing, power analysis) can leak private keys if implementations aren’t carefully hardened. Use well-audited libraries (liboqs, BoringSSL, OpenSSL 3.2+) rather than rolling your own.

• Quantum computers are coming. Current estimates suggest 10-15 years, but breakthroughs could accelerate this. If your data must remain secret for 20+ years, migrate to hybrid mode now. “Harvest Now, Decrypt Later” attacks are already happening.

• Don’t roll your own crypto. Post-quantum cryptography is complex. Use standardized algorithms (ML-KEM, ML-DSA, SLH-DSA, FN-DSA) from NIST, implemented in well-audited libraries. Avoid proprietary or unvetted schemes.

Migration Checklist

Ready to migrate to post-quantum cryptography? Follow this checklist:

Phase 1: Inventory (Weeks 1-4)

• Inventory all cryptographic assets — Catalog every system, protocol, and library that uses RSA, ECC, or other quantum-vulnerable algorithms
• Identify long-lived data — Prioritize data that must remain confidential for 10+ years (these are at immediate risk from HNDL attacks)
• Assess dependencies — Map third-party vendors, cloud providers, and partners that need to support PQC

Phase 2: Hybrid Deployment (Weeks 5-12)

• Enable hybrid key exchange in TLS — Configure your web servers to support X25519 + ML-KEM-768 (OpenSSL 3.2+, BoringSSL, or cloud provider settings)
• Update SSH configurations — Enable [email protected] for hybrid key exchange
• Test with clients — Verify that browsers, mobile apps, and IoT devices can negotiate hybrid TLS connections
• Monitor performance — Track latency, throughput, and error rates after enabling hybrid mode

Phase 3: Full PQC Migration (Months 4-12)

• Deploy ML-DSA signatures — Start using ML-DSA-65 for code signing, document signing, or internal certificates
• Update PKI infrastructure — Work with your certificate authority to issue PQC-enabled X.509 certificates
• Migrate legacy systems — Gradually replace RSA/ECC-only systems with PQC-capable alternatives
• Remove classical algorithms — Once PQC is fully trusted, disable RSA/ECC fallbacks (optional, depends on compliance requirements)

Phase 4: Ongoing (Continuous)

• Monitor NIST updates — Stay informed about new PQC standards, algorithm updates, or security advisories
• Rotate keys regularly — Follow the same key rotation policies as classical cryptography (annual for active keys, immediate on compromise)
• Audit implementations — Regularly review PQC implementations for side-channel vulnerabilities or configuration errors

Frequently Asked Questions

When will quantum computers break RSA and ECC?

Current estimates from the Global Risk Institute suggest a >50% probability that a cryptographically relevant quantum computer will exist within 15 years². Most experts predict Q-Day (the day RSA-2048 can be broken) will occur between 2030 and 2040. However, “Harvest Now, Decrypt Later” attacks are already happening — adversaries are stockpiling encrypted data today to decrypt it when quantum computers arrive. If your data must remain secret for 10+ years, you need to migrate now.

What is the difference between ML-KEM and ML-DSA?

ML-KEM (Kyber) is for key encapsulation — securely exchanging symmetric keys over insecure channels. It replaces RSA key exchange and ECDHE in TLS, SSH, and other protocols. ML-DSA (Dilithium) is for digital signatures — proving authenticity and integrity of data. It replaces RSA signatures, ECDSA, and Ed25519. Both are based on Module-LWE (lattice problems), but they serve different purposes. You typically use ML-KEM for key exchange and ML-DSA for signatures.

Are post-quantum algorithms slower than RSA/ECC?

It depends on the algorithm. ML-KEM key encapsulation is comparable in speed to X25519 (~0.3ms vs ~0.1ms). ML-DSA signing is slower than Ed25519 (~1.5ms vs ~0.02ms), but verification is comparable (~2ms vs ~0.06ms). SLH-DSA signing is very slow (~0.5-3 seconds), but verification is fast. The main performance impact is larger key and signature sizes, which increase bandwidth and storage requirements. For most applications, the performance difference is negligible.

Can I use post-quantum cryptography today?

Yes. Hybrid mode (X25519 + ML-KEM-768) is already supported in TLS 1.3 by Chrome, Firefox, Cloudflare, and OpenSSL 3.2+. Signal, Apple iMessage, and OpenSSH support hybrid key exchange. For signatures, ML-DSA is supported in OpenSSL 3.2+, BoringSSL, and liboqs. Our ML-KEM Key Encapsulation and ML-DSA Sign/Verify tools let you experiment with PQC right now in your browser.

What about AES-256? Is it quantum-safe?

Yes. AES-256 is considered quantum-resistant. Grover’s algorithm can speed up brute-force attacks, but it only reduces AES-256’s security from 256 bits to 128 bits — still computationally infeasible. AES-128 would be reduced to 64 bits (breakable), so you should use AES-256 for long-term security. Symmetric encryption is much less affected by quantum computers than asymmetric encryption (RSA/ECC).

Do I need to migrate to post-quantum cryptography now?

It depends on your data’s sensitivity and shelf life. If you’re protecting data that must remain confidential for 10+ years (healthcare records, financial data, government secrets, intellectual property), you should start migrating now using hybrid mode. If you’re protecting short-lived data (session keys, temporary messages), you can wait a few years. The safest approach: enable hybrid mode today for defense-in-depth, then fully migrate to PQC-only over the next 3-5 years.

What is “Harvest Now, Decrypt Later” (HNDL)?

HNDL is an attack where adversaries collect encrypted data today and store it until quantum computers can decrypt it. This is already happening at nation-state level — intelligence agencies are likely stockpiling diplomatic cables, financial transactions, and corporate secrets. Even if quantum computers are 15 years away, data encrypted today with RSA/ECC can be decrypted in the future. This is why migration urgency depends on how long your data needs to stay secret, not just when Q-Day arrives.

Which post-quantum algorithm should I use?

For key exchange, use ML-KEM-768 in hybrid mode (X25519 + ML-KEM-768). For signatures, use ML-DSA-65 (primary) or FN-DSA-512 (if you need compact signatures). SLH-DSA is a conservative backup with minimal trust assumptions, but it’s slow and produces large signatures. For most applications, ML-KEM + ML-DSA in hybrid mode is the recommended choice.

Related Tools

• ML-KEM Key Encapsulation — Experiment with ML-KEM-512/768/1024 key encapsulation in your browser. Generate key pairs, encapsulate and decapsulate shared secrets.

• ML-DSA Sign/Verify — Sign messages and verify signatures with ML-DSA-44/65/87. Supports PEM key import/export.

• RSA Key Generator — Generate classical RSA key pairs for comparison with post-quantum algorithms.

• ECC Key Generator — Generate classical ECC key pairs (P-256, Ed25519) for hybrid mode experimentation.

• Ed25519 Sign/Verify — Sign messages with classical Ed25519 for comparison with ML-DSA.

Further Reading

• NIST FIPS 203 — ML-KEM (Kyber)
• NIST FIPS 204 — ML-DSA (Dilithium)
• NIST FIPS 205 — SLH-DSA (SPHINCS+)
• NIST IR 8547 — Transition to Post-Quantum Cryptography Standards
• Open Quantum Safe (liboqs) — Open-source PQC library
• Global Risk Institute — Quantum Computing Threat Timeline

Related Articles

• RSA-2048 Encryption: The Complete Guide — The classical algorithm that post-quantum cryptography aims to replace
• Elliptic Curve Cryptography (ECC): The Complete Guide — Also vulnerable to quantum attacks via Shor’s algorithm
• How Digital Signatures Work — Understanding the signature schemes that ML-DSA and SLH-DSA replace
• How TLS Protects Your Internet Connection — How post-quantum key exchange (ML-KEM) is being integrated into TLS 1.3
• Cryptographic Key Management — Managing the transition to quantum-resistant key management infrastructure

---

¹ Source: Global Risk Institute 2025 survey of industry leaders
² Source: Global Risk Institute quantum computing probability estimates