Post-quantum cryptography is no longer “research.” It’s three FIPS standards. Major implementations (OpenSSL 3.5, BoringSSL, AWS-LC, Cloudflare, Google) ship them in production code. The job now is migration — and migration starts with knowing what each algorithm is for.
The three NIST PQ standards
FIPS 203 — ML-KEM (Module-Lattice-based Key-Encapsulation Mechanism). Formerly known as CRYSTALS-Kyber. Replaces: RSA encryption, RSA-OAEP, ECDH key exchange. Use when: you need to securely exchange a symmetric key over an insecure channel (TLS, IPsec, SSH KEX, encrypted email).
FIPS 204 — ML-DSA (Module-Lattice-based Digital Signature Algorithm). Formerly known as CRYSTALS-Dilithium. Replaces: RSA signatures, ECDSA, EdDSA. Use when: you need to sign data — code signing, document signing, JWT signing, certificate authorities, smart-card auth.
FIPS 205 — SLH-DSA (Stateless Hash-based Digital Signature Algorithm). Formerly known as SPHINCS+. Conservative alternative to ML-DSA — uses only hash function security, no lattice assumptions. Use when: you want maximum confidence (firmware signing on long-lifetime devices, root certificates with 30-year lifespan).
Each comes in three security levels (NIST L1, L3, L5) corresponding roughly to AES-128, AES-192, AES-256 equivalent classical security.
What replaces what — the migration map
| Today (classical) | Tomorrow (PQ) | Use case |
|---|---|---|
| RSA-2048 (encryption) | ML-KEM-768 | TLS key exchange |
| ECDH P-256 | ML-KEM-768 | TLS, IPsec, SSH KEX |
| RSA-2048 (signatures) | ML-DSA-65 | Cert signing, JWT |
| ECDSA P-256 | ML-DSA-65 | Code signing, blockchain |
| Long-lived RSA roots | SLH-DSA-256s | CA root certs, firmware |
| AES-128 | AES-256 (no change required) | Bulk encryption |
| SHA-256 | SHA-256 or SHA-384 for high-assurance | Integrity, HMAC |
Size impact — the practical cost
PQ algorithms have larger key/ciphertext/signature sizes than classical equivalents. This affects bandwidth, certificate storage, and TLS handshake performance.
| Operation | Classical (RSA-2048) | PQ (ML-KEM/DSA) |
|---|---|---|
| Public key | 256 bytes | 1184 bytes (ML-KEM-768) / 1952 bytes (ML-DSA-65) |
| Ciphertext / signature | 256 bytes | 1088 bytes (ML-KEM-768) / 3309 bytes (ML-DSA-65) |
| SLH-DSA signature | N/A | ~7800 bytes (SLH-DSA-128s) |
Practical impact:
- TLS handshake adds ~1-3KB. Modern networks handle this comfortably.
- Embedded/IoT devices with constrained bandwidth or tiny flash storage feel the pinch — pick smaller variants (ML-KEM-512) or stick to classical until SLH-DSA isn’t needed.
- Certificate chain size grows proportionally. For roots that already use 4096-bit RSA, PQ may not be much worse.
Hybrid mode — running both during migration
The transitional pattern: TLS 1.3 negotiates BOTH classical AND PQ key exchange in the same handshake. The session key is derived from both. Security guarantee: an adversary needs to break BOTH (classical AND PQ) to get the session key.
Cloudflare and Google deployed hybrid X25519+ML-KEM-768 to production in 2024. Chrome 124+, Firefox 132+, Safari 17.4+ negotiate it automatically. Browsers don’t display this; users don’t know it’s happening; it just works.
Hybrid mode is the right migration step. It’s already done for you on the Cloudflare-and-modern-browser side. Your origins need to support it (most modern proxy/load-balancer software does as of late 2025).
What’s NOT in NIST’s standards
NIST evaluated dozens of PQ candidates. Several didn’t make the cut:
- SIKE — isogeny-based KEM. Broken by Castryck-Decru attack in 2022. Removed from NIST process.
- Rainbow — multivariate signature. Broken by Beullens 2022 attack. Removed.
- Classic McEliece — code-based KEM. Excellent security, very large keys (1+ MB). NIST may finalise as alternative; currently not standardised.
- FALCON — lattice signature, smaller than ML-DSA but more complex. NIST may publish as additional standard (FN-DSA) in 2025-2026 timeframe.
- BIKE / HQC — code-based KEMs being evaluated as ML-KEM alternatives.
Practical recommendation: stick to FIPS 203 / 204 / 205 unless you have specific use cases that need alternatives.
Where you can use PQ today
- OpenSSL 3.5 (released 2025) — native ML-KEM, ML-DSA, SLH-DSA support.
- BoringSSL (Chrome / Cloudflare) — production hybrid Kyber.
- AWS-LC (AWS) — production PQ.
- Cloudflare Origin TLS — auto-negotiates hybrid X25519+Kyber-768 on supported origins.
- OQS-OpenSSH — Open Quantum Safe project’s fork supports PQ KEX in SSH.
- WolfSSL — embedded TLS with PQ support.
- Microsoft Azure Quantum-Safe Crypto Library — preview-stage.
FAQ
Should I generate new PQ certificates from my CA today?
Most CAs (DigiCert, Sectigo, Let’s Encrypt) don’t yet issue ML-DSA leaf certificates. Wait for that. For end-entity certs, hybrid TLS handles the asymmetric replacement at the protocol layer; certificates remain ECDSA/RSA for now.
Is hybrid mode just temporary?
The current hybrid mode (classical + PQ) is the migration path. Eventually pure-PQ mode will dominate; hybrids will phase out probably 2030-2035. For now, hybrid is the conservative answer — survives if either component breaks.
What about VPN / IPsec migration?
IKEv2 has draft support for PQ KEM. Cisco, Fortinet, Palo Alto are shipping experimental PQ IKE. Production-stable in 2025-2026 timeframe.
Will SSH break when I migrate?
OpenSSH 9.0+ supports sntrup761x25519-sha512 (a hybrid PQ KEM) by default. OpenSSH 9.9+ supports mlkem768x25519-sha256 (the standardised version). Migration is transparent to most users.
Does this affect Indian compliance — RBI, SEBI, DPDP?
Not yet specified by Indian regulators. Multinationals operating in India should align to NIST timeline (2030-2035) anyway. Indian-only entities can wait for sectoral guidance, but should at minimum inventory cryptographic dependencies and prepare for migration.
⚖️ Module 5 of 20. Foundational PQ standards overview. Modules 6-10 (Intermediate) cover each algorithm in depth and the migration mechanics.
Custom team training + practitioner advisory
Beyond the free academy — we run private workshops, vCISO advisory, and red-team exercises tailored to your stack. For Indian SMBs scaling past their first hire.