⚛ Quantum Security
PQC Algorithm Reference
Plain-English guide to NIST's finalized post-quantum cryptography standards. What each algorithm does, what it replaces, key sizes, and where to deploy it.
ML-KEM
FIPS 203 — Finalized August 2024
Module-Lattice Key Encapsulation Mechanism — previously known as CRYSTALS-Kyber
Key Exchange
Replaces:
RSA key exchange
→
ECDH / ECDHE
Diffie-Hellman
→
ML-KEM-768 or ML-KEM-1024
Security Levels
ML-KEM-512 (L1), ML-KEM-768 (L3), ML-KEM-1024 (L5)
Recommended Level
ML-KEM-768 (equivalent to AES-192)
Public Key Size
ML-KEM-768: 1,184 bytes (vs 32 bytes for ECDH P-256)
Performance
Extremely fast — faster than RSA-2048 for key generation
Hard Problem
Module Learning With Errors (MLWE) — lattice-based
Status
Finalized — supported in OpenSSL 3.5+, AWS, Azure, Cloudflare
What it does: ML-KEM establishes a shared secret between two parties — like agreeing on an encryption key over an insecure channel — without any eavesdropper being able to derive that secret, even with a quantum computer. It replaces ECDH (used in TLS handshakes, SSH, VPNs, Signal protocol) and RSA key encapsulation.
Where to deploy ML-KEM first
TLS 1.3 key exchange (highest priority — protects against HNDL attacks), VPN key establishment, SSH session key exchange, encrypted messaging key agreement.
Already in production: Cloudflare, Google, Amazon, and Signal all use ML-KEM (or its predecessor Kyber) in production hybrid TLS today. Google Chrome supports X25519Kyber768 since Chrome 116. Your users are already using it when visiting Google.
ML-DSA
FIPS 204 — Finalized August 2024
Module-Lattice Digital Signature Algorithm — previously known as CRYSTALS-Dilithium
Digital Signatures
Replaces:
RSA-PSS / RSA-PKCS#1
ECDSA
EdDSA (Ed25519)
→
ML-DSA-65 or ML-DSA-87
Security Levels
ML-DSA-44 (L2), ML-DSA-65 (L3), ML-DSA-87 (L5)
Recommended Level
ML-DSA-65 for most use cases
Signature Size
ML-DSA-65: 3,309 bytes (vs 64 bytes for Ed25519)
Performance
Fast signing and verification — better than RSA-2048
Hard Problem
Module Short Integer Solution (MSIS) — lattice-based
Status
Finalized — Java 24+, OpenSSL 3.5+, BouncyCastle
What it does: ML-DSA creates unforgeable digital signatures that verify authenticity and integrity of data or messages. A quantum computer running Shor's algorithm can forge ECDSA and RSA signatures — ML-DSA is resistant to this attack.
Where to deploy ML-DSA first
Code signing (software, firmware, documents), TLS certificates (once CAs begin issuing PQC certificates), JWT signing for long-lived tokens, document authentication, PKI root and intermediate CA certificates.
Important: Signature sizes in ML-DSA are significantly larger than classical signatures. This impacts protocols that embed signatures in packets (DNSSEC, some IoT protocols). Test bandwidth impact before deploying in constrained environments.
SLH-DSA
FIPS 205 — Finalized August 2024
Stateless Hash-Based Digital Signature Algorithm — previously known as SPHINCS+
Hash-Based Signatures
Replaces:
RSA signatures
ECDSA
→
SLH-DSA-SHA2-128s or SLH-DSA-SHA2-256s
Security Approach
Hash-based — security relies only on hash function security
Key Advantage
Most conservative security assumptions of any PQC algorithm
Signature Size
7,856 bytes (fast variant) to 49,856 bytes (small keys)
Performance
Slower than ML-DSA — best for infrequent, high-value signatures
Hard Problem
One-wayness of hash functions (SHA2 or SHAKE)
Best Use
Root CA certificates, software signing, long-lived artifacts
What it does: SLH-DSA is the most conservative PQC signature scheme. Its security relies only on the security of hash functions (SHA2 or SHAKE) — not on lattice assumptions. If lattice-based cryptography (ML-KEM, ML-DSA) were later broken, SLH-DSA would remain secure. Use it for the highest-value, lowest-frequency signing operations.
When to choose SLH-DSA over ML-DSA: Root CA key signing (done rarely, must remain secure for 20+ years), firmware signing for critical infrastructure, offline signing of high-value artefacts. Use ML-DSA for frequent, online signing operations.
FALCON
FIPS 206 (Draft) — Standardization in progress
Fast Fourier Lattice-based Compact Signatures over NTRU
Compact Signatures
Key Advantage
Smallest signatures of any lattice-based scheme — 666-1280 bytes
Performance
Fast verification, slower signing — not constant time (implementation complexity)
Hard Problem
NTRU lattice — different from ML-DSA (lattice diversity)
Status
Draft standard — being finalized as FIPS 206
Best For
Bandwidth-constrained environments — blockchain, IoT, embedded
Caution
Complex implementation — side-channel attack risk if done incorrectly
FALCON is the compact alternative to ML-DSA. Its smaller signature sizes make it suitable for environments where bandwidth is constrained. However, its implementation complexity means it should only be used by teams with strong cryptographic engineering capability — subtle implementation errors can leak private keys via side channels.
📊 Algorithm Comparison: Classical vs Post-Quantum
Key Exchange / Key Encapsulation
| Algorithm | Quantum Safe? | Public Key | Ciphertext/Share | Speed | Status |
|---|---|---|---|---|---|
| RSA-2048 | Broken by Shor's | 256 bytes | 256 bytes | Slow | Avoid for new deployments |
| ECDH P-256 | Broken by Shor's | 64 bytes | 32 bytes | Fast | Avoid for new deployments |
| X25519 | Broken by Shor's | 32 bytes | 32 bytes | Very fast | Use in hybrid only |
| ML-KEM-512 | Quantum safe | 800 bytes | 768 bytes | Very fast | FIPS 203 — Level 1 |
| ML-KEM-768 | Quantum safe | 1,184 bytes | 1,088 bytes | Very fast | FIPS 203 — Recommended |
| ML-KEM-1024 | Quantum safe | 1,568 bytes | 1,568 bytes | Fast | FIPS 203 — Maximum |
Digital Signatures
| Algorithm | Quantum Safe? | Public Key | Signature Size | Speed | Best Use |
|---|---|---|---|---|---|
| RSA-PSS-2048 | Broken by Shor's | 256 bytes | 256 bytes | Slow sign | Migrate away |
| ECDSA P-256 | Broken by Shor's | 64 bytes | 64 bytes | Fast | Migrate away |
| Ed25519 | Broken by Shor's | 32 bytes | 64 bytes | Very fast | Hybrid use only |
| ML-DSA-44 | Quantum safe | 1,312 bytes | 2,420 bytes | Fast | FIPS 204 — Level 2 |
| ML-DSA-65 | Quantum safe | 1,952 bytes | 3,309 bytes | Fast | FIPS 204 — Recommended |
| ML-DSA-87 | Quantum safe | 2,592 bytes | 4,627 bytes | Fast | FIPS 204 — Level 5 |
| SLH-DSA-SHA2-128s | Quantum safe | 32 bytes | 7,856 bytes | Very slow sign | FIPS 205 — root CAs, firmware |
| SLH-DSA-SHA2-256s | Quantum safe | 64 bytes | 29,792 bytes | Very slow sign | FIPS 205 — max security |
| FALCON-512 | Quantum safe | 897 bytes | 666 bytes | Fast verify | FIPS 206 — compact bandwidth |
Symmetric algorithms — still secure
AES, SHA-2, SHA-3 are NOT broken by quantum computers. Grover's algorithm provides a quadratic speedup but not an exponential one. AES-128 drops to ~64-bit effective security against quantum — AES-256 remains effectively secure. Recommendation: migrate from AES-128 to AES-256 as a precautionary measure. Your symmetric algorithms do NOT need to be replaced.
🚀 Where to Deploy Each Algorithm
| Use Case | Algorithm | Priority | Notes |
|---|---|---|---|
| TLS key exchange | ML-KEM-768 (hybrid with X25519) | Critical | Protects against HNDL — highest priority. Enable now in hybrid mode. |
| TLS certificate signature | ML-DSA-65 (when CAs support) | High | Wait for CA ecosystem support — transitioning slower than key exchange. |
| Code signing | ML-DSA-65 or SLH-DSA-SHA2-128s | High | Use SLH-DSA for root signing keys. ML-DSA for routine signing. |
| SSH session keys | ML-KEM-768 (hybrid) | High | OpenSSH 9.0+ supports hybrid Kyber. Update server and client configs. |
| SSH host authentication | ML-DSA-65 | Medium | Secondary to session key exchange. Update after key exchange migration. |
| VPN key exchange | ML-KEM-768 (hybrid) | High | IPSec/IKEv2 with hybrid PQC. Check vendor support (StrongSwan, WireGuard). |
| PKI root CA | SLH-DSA-SHA2-256s | Medium | Longest-lived keys — use most conservative algorithm. Plan carefully. |
| PKI intermediate CA | ML-DSA-87 or SLH-DSA-SHA2-128s | Medium | Balance security and performance. Intermediate CAs rotated more frequently. |
| JWT signing (long-lived) | ML-DSA-65 | Standard | Replace ES256/RS256 in JWT header. Library support growing (BouncyCastle, etc.) |
| Document signing | ML-DSA-65 | Standard | PDF/XML digital signatures. Wait for tool support — Adobe, DocuSign roadmaps. |
| HSM-protected keys | ML-KEM-768 + ML-DSA-65 | High | Verify HSM firmware PQC support before migration. May require hardware replacement. |
💻 Code Examples — Enabling PQC
OpenSSL 3.5+ — ML-KEM in TLS
# Verify OpenSSL PQC support
openssl list -kem-algorithms | grep -i kyber
openssl list -kem-algorithms | grep -i mlkem
# Generate ML-KEM-768 key pair
openssl genpkey -algorithm mlkem768 -out server_mlkem.key
openssl pkey -in server_mlkem.key -pubout -out server_mlkem_pub.key
# TLS server with hybrid PQC (ML-KEM-768 + X25519)
# Configure in openssl.cnf or nginx/apache config:
# ssl_conf_command Groups X25519MLKEM768:X25519:P-256 (nginx)
# Test hybrid TLS connection
openssl s_client -connect yourserver.com:443 \
-groups X25519MLKEM768 \
-tls1_3
# Look for: Server Temp Key: ML-KEM, 768 bits
Python — ML-DSA signatures with liboqs
pip install pyoqs
import oqs
# ML-DSA-65 key generation and signing
with oqs.Signature("ML-DSA-65") as signer:
public_key = signer.generate_keypair()
private_key = signer.export_secret_key()
message = b"CERT-In Incident Report - 2025-07-26"
signature = signer.sign(message)
print(f"Signature size: {len(signature)} bytes") # ~3,309 bytes
# Verification
with oqs.Signature("ML-DSA-65") as verifier:
is_valid = verifier.verify(message, signature, public_key)
print(f"Valid: {is_valid}") # True
# ML-KEM-768 key encapsulation
with oqs.KeyEncapsulation("ML-KEM-768") as kem:
public_key = kem.generate_keypair()
ciphertext, shared_secret_sender = kem.encap_secret(public_key)
shared_secret_recipient = kem.decap_secret(ciphertext)
assert shared_secret_sender == shared_secret_recipient
print(f"Shared secret established: {shared_secret_sender.hex()[:16]}...")
🔀 Hybrid Mode — The Safe Transition Strategy
Hybrid mode runs a classical algorithm (X25519, ECDSA) in parallel with a PQC algorithm (ML-KEM, ML-DSA). The combined security is at least as strong as the stronger of the two. If PQC is broken (unlikely but possible — these are new algorithms), classical crypto still protects you. If classical crypto is broken by quantum, PQC still protects you.
Recommendation: Always deploy in hybrid mode first. Never replace classical algorithms entirely until the PQC algorithms have been in widespread production use for several years and have survived extensive cryptanalysis. The hybrid approach is endorsed by NIST, NSA, ENISA, and NCSC (UK).
Hybrid combinations in production today
| Hybrid Combination | Where Used | Support |
|---|---|---|
| X25519Kyber768 / X25519MLKEM768 | TLS 1.3 key exchange | Chrome 116+, Firefox, Cloudflare, Google, AWS |
| P256Kyber768 / P256MLKEM768 | TLS 1.3 key exchange (FIPS environments) | BoringSSL, some enterprise products |
| ssh-kyber768-x25519 | SSH session key exchange | OpenSSH 9.0+ (hybrid KEX) |
| ECDSA + ML-DSA composite | X.509 certificates | Draft IETF RFC — not yet production |
Hybrid TLS configuration (nginx)
# nginx with OpenSSL 3.5+ — enable hybrid PQC TLS
server {
listen 443 ssl;
ssl_certificate /etc/nginx/certs/server.crt;
ssl_certificate_key /etc/nginx/certs/server.key;
ssl_protocols TLSv1.3;
# Prefer hybrid PQC, fall back to classical
ssl_conf_command Groups X25519MLKEM768:X25519:P-256:P-384;
# Verify with: openssl s_client -connect yourserver:443 -tls1_3
# Look for: Server Temp Key: ML-KEM, 768 bits
}
📅 PQC Migration Timeline
2024 — Completed
NIST finalizes FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA) in August 2024. The standards are done — migration can begin in earnest.
2025 — Now
OpenSSL 3.5 released with ML-KEM and ML-DSA support. Java 24 includes ML-KEM. AWS KMS, Azure Key Vault adding PQC key types. NSA mandates PQC for US national security systems. Early adopters begin production hybrid TLS deployments. Indian National Quantum Mission active — DRDO QKD projects progressing.
2026-2027 — Early majority
Certificate Authorities begin issuing PQC and hybrid X.509 certificates. Major cloud providers complete PQC TLS rollout. Browser vendors fully support hybrid PQC. CERT-In and RBI expected to begin PQC guidance consultations. Indian enterprises begin formal migration programmes.
2028-2030 — Mainstream
PQC becomes default in new deployments. Classical-only deployments become non-compliant for regulated sectors. Indian regulators expected to set migration deadlines. HSM vendors complete PQC firmware rollout. Enterprise PKI migrations largely complete.
2030-2035 — Deprecation
NIST and NSA deprecate RSA and ECC for new systems. Classical-only crypto no longer approved for sensitive government and financial applications. Cryptographically relevant quantum computer (CRQC) timelines remain uncertain but the migration must complete well before arrival.
2035+ — CRQC risk window
Estimates for a cryptographically relevant quantum computer (capable of breaking RSA-2048 in hours) range from 2030 to 2040+. No one knows exactly when. The HNDL threat means traffic captured TODAY is at risk even if CRQC arrives in 2035. Start now.