ML-KEM vs ML-DSA vs SLH-DSA are not competing solutions to the same problem—they are three NIST-standardized post-quantum cryptographic primitives serving fundamentally different functions. Selecting the wrong algorithm for a given use case does not result in reduced security; it results in a system that fails to meet its intended purpose. This guide provides the technical clarity required for engineers and security leaders to make correct deployment decisions across environments in 2026.
What NIST Actually Published — and Why It Matters
In August 2024, the National Institute of Standards and Technology (NIST) finalized the first three post-quantum cryptography standards following an eight-year global evaluation involving 82 candidate algorithms from researchers across 25 countries. The resulting standards—ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205)—are all approved for deployment today.
The critical distinction underpinning any ML-KEM vs ML-DSA vs SLH-DSA comparison is functional: ML-KEM is a Key Encapsulation Mechanism used to establish shared secrets over insecure channels, while ML-DSA and SLH-DSA are Digital Signature Algorithms used to authenticate identity and ensure data integrity. These roles are not interchangeable—key exchange and digital signatures solve different cryptographic problems and must be deployed accordingly.
⚠ Technical Disclaimer: This article is for educational and informational purposes only. It does not constitute professional cybersecurity, cryptographic, or legal advice. Organizations should engage qualified cryptography professionals before implementing cryptographic changes.
The Three NIST Post-Quantum Standards — What Each Algorithm Actually Does
The single most important conceptual distinction in the NIST PQC standards is the difference between a Key Encapsulation Mechanism (KEM) and a Digital Signature Algorithm. ML-KEM (FIPS 203) is a KEM — it establishes a shared secret key between two parties over an insecure channel [2].
ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) are digital signature algorithms — they authenticate the identity of a signer and verify the integrity of a message or document [3][4]. A system that needs to secure a TLS handshake needs a KEM. A system that needs to sign firmware needs a signature algorithm. These are not substitutable functions.
Table 1: Summary of the three NIST post-quantum cryptography standards — function, mathematical foundation, and what each replaces in classical cryptography.
| Standard | Algorithm | Function | Math Foundation | Replaces (Classical) |
| FIPS 203 | ML-KEM | Key Encapsulation (KEM) | Module Learning With Errors (Module-LWE) — lattice-based | RSA key transport, ECDH / ECDHE, Diffie-Hellman |
| FIPS 204 | ML-DSA | Digital Signatures | Module Learning With Errors (Module-LWE) — lattice-based | RSA signatures, ECDSA, EdDSA |
| FIPS 205 | SLH-DSA | Digital Signatures (backup/diversity) | Hash functions only (SHA-2 / SHAKE) — not lattice-based | ECDSA (as a conservative alternative to ML-DSA) |
The Three Algorithms Explained Side by Side
ML-KEM (FIPS 203) — Key Exchange, Not Signatures
ML-KEM, derived from CRYSTALS-Kyber and developed with IBM Research, establishes a shared encryption key between two parties over an insecure channel. It replaces RSA key transport and Elliptic Curve Diffie-Hellman (ECDH) in TLS, VPNs, and encrypted messaging protocols [2].
Its security rests on the Module Learning With Errors (Module-LWE) problem — finding a short vector in a high-dimensional lattice — for which no efficient quantum algorithm exists. NIST specifies three parameter sets: ML-KEM-512, ML-KEM-768, and ML-KEM-1024. For most enterprise deployments, ML-KEM-768 in hybrid mode with X25519 is the recommended default, a configuration already running at internet scale across Cloudflare’s global network. [6]
ML-DSA (FIPS 204) — Performance vs RSA-2048 and the Primary Post-Quantum Signature Standard
ML-DSA, derived from CRYSTALS-Dilithium, is the general-purpose post-quantum digital signature algorithm. It replaces ECDSA and RSA signatures in code signing pipelines, certificate authorities, authentication tokens, and document integrity verification workflows.
Like ML-KEM, ML-DSA is built on Module-LWE mathematics. It offers three parameter sets — ML-DSA-44, ML-DSA-65, and ML-DSA-87. Performance benchmarks published in 2025 show that ML-DSA-65 signs approximately ten times faster than RSA-2048 [10], at 100–200 microseconds per signing operation versus 2–5 milliseconds for RSA-2048. The NSA CNSA 2.0 suite approves ML-DSA for all signing use cases in National Security Systems, with exclusive use mandated by 2030[8].
SLH-DSA (FIPS 205) — The Hash-Based Diversity Standard
SLH-DSA, derived from SPHINCS+, is the stateless hash-based digital signature algorithm NIST recommends as a mathematical diversity hedge. Unlike ML-KEM and ML-DSA, which both depend on lattice mathematics, SLH-DSA derives its security entirely from cryptographic hash functions — SHA-2 and SHAKE — among the most extensively studied constructs in applied cryptography.
This distinction matters critically in any ML-KEM vs ML-DSA vs SLH-DSA evaluation: if a fundamental flaw were discovered in Module-LWE, both ML-KEM and ML-DSA would be simultaneously vulnerable. SLH-DSA, operating under independent security assumptions, would remain secure. NIST’s 2022 evaluation period demonstrated the practical importance of this diversity — SIKE, a widely-praised candidate, was completely broken by classical computers with no quantum advantage required.
SLH-DSA is not included in CNSA 2.0 and is not approved for National Security System deployments. It is appropriate for commercial use cases requiring algorithmic diversity or long-lived archival signatures.
💡 For more information,
→ View all Post-Quantum Security series articles here
Key Sizes and Signatures — The Numbers That Change Your Infrastructure
The most immediate practical consequence of deploying any of the three standards is the increase in key and signature sizes relative to classical cryptography — and understanding the post-quantum algorithm key sizes infrastructure impact is essential before any migration begins. Capacity planning, protocol buffer sizing, certificate chain limits, and API payload constraints all require adjustment when signature sizes jump from 64 bytes to 3,309 bytes.
Understanding these numbers is essential for capacity planning, protocol design, and evaluating the performance impact on existing infrastructure[7]. Table 2 provides exact byte-level figures for all parameter variants of all three standards, derived from the NIST FIPS publications and corroborated by benchmarking research published in 2025 and 2026.
Table 2: Exact key, ciphertext, and signature sizes for all NIST post-quantum cryptography parameter variants, compared to classical cryptographic equivalents.
| Algorithm | Variant | Public Key (bytes) | Ciphertext / Signature (bytes) | Classical Equivalent for Comparison | Security Level (NIST) |
| ML-KEM | ML-KEM-512 | 800 | 768 (ciphertext) | X25519: 32 bytes public key | Level 1 ≈ AES-128 |
| ML-KEM | ML-KEM-768 (recommended) | 1,184 | 1,088 (ciphertext) | X25519: 32 bytes public key | Level 3 ≈ AES-192 |
| ML-KEM | ML-KEM-1024 | 1,568 | 1,568 (ciphertext) | X25519: 32 bytes public key | Level 5 ≈ AES-256 |
| ML-DSA | ML-DSA-44 | 1,312 | 2,420 (signature) | ECDSA P-256: 64 bytes sig | Level 2 ≈ AES-128 |
| ML-DSA | ML-DSA-65 (recommended) | 1,952 | 3,309 (signature) | Ed25519: 64 bytes sig | Level 3 ≈ AES-192 |
| ML-DSA | ML-DSA-87 | 2,592 | 4,627 (signature) | Ed25519: 64 bytes sig | Level 5 ≈ AES-256 |
| SLH-DSA | SLH-DSA-128s (small/slow) | 32 | 7,856 (signature) | ECDSA P-256: 64 bytes sig | Level 1 ≈ AES-128 |
| SLH-DSA | SLH-DSA-128f (fast/large) | 32 | 17,088 (signature) | ECDSA P-256: 64 bytes sig | Level 1 ≈ AES-128 |
| SLH-DSA | SLH-DSA-256s (small/slow) | 64 | 29,792 (signature) | ECDSA P-256: 64 bytes sig | Level 5 ≈ AES-256 |
| SLH-DSA | SLH-DSA-256f (fast/large) | 64 | 49,856 (signature) | ECDSA P-256: 64 bytes sig | Level 5 ≈ AES-256 |
★ Recommended variant for most enterprise deployments
For TLS: An ML-KEM-768 handshake adds approximately 2 KB of overhead versus 32 bytes for X25519. Cloudflare’s production data confirms negligible latency impact at scale.[6]
For signatures: An ML-DSA-65 signature is roughly 52x larger than Ed25519. SLH-DSA-128s signatures are approximately 123x larger — both remain within practical bounds for most enterprise workflows. [7]
Security Assumptions — Why Two Math Foundations Are Better Than One
In any ML-KEM vs ML-DSA vs SLH-DSA comparison, security assumptions represent the most strategically significant dimension. ML-KEM and ML-DSA share the same Module-LWE mathematical foundation. SLH-DSA does not. This creates a correlated failure risk: a breakthrough against Module-LWE would compromise both lattice-based standards simultaneously, while leaving SLH-DSA entirely intact.[4]
No practical attack against Module-LWE is known as of 2026, and both algorithms underwent eight years of rigorous scrutiny during the NIST evaluation process. However, the SIKE break — a complete classical attack against a leading PQC candidate — demonstrated that no algorithm family should be treated as immune to future cryptanalysis. Maintaining at least one deployed signature algorithm based on hash-based security assumptions is a risk management discipline, not theoretical overcaution
Algorithm Selection Matrix — Which Standard Belongs Where
For organizations subject to CNSA 2.0, the approved algorithms list for 2026 is ML-KEM and ML-DSA only — SLH-DSA is explicitly excluded from National Security System deployments [8]. The correct choice in any ML-KEM vs ML-DSA vs SLH-DSA deployment decision depends on three factors: the cryptographic function required, the performance and size constraints of the environment, and applicable regulatory frameworks such as CNSA 2.0 [8].
Table 3: Post-quantum algorithm selection decision matrix — recommended algorithm, variant, and rationale for seven enterprise deployment scenarios.
| Use Case | Recommended Algorithm | Recommended Variant |
| TLS 1.3 key exchange (internet-facing) | ML-KEM | ML-KEM-768 + X25519 hybrid |
| VPN / IPsec key exchange | ML-KEM | ML-KEM-768 (enterprise); ML-KEM-1024 (NSS/CNSA 2.0) |
| Code signing and firmware authentication | ML-DSA | ML-DSA-65 (enterprise); ML-DSA-87 (highest security) |
| Certificate authorities and PKI | ML-DSA | ML-DSA-65 (leaf CAs); ML-DSA-87 (root CAs) |
| Long-lived archival signatures (decades) | SLH-DSA | SLH-DSA-128s (min size); SLH-DSA-256s (max security) |
| Lattice-risk hedge / algorithm diversity | SLH-DSA | SLH-DSA-SHA2 or SHAKE variant per use case |
| High-frequency API authentication tokens | ML-DSA | ML-DSA-44 (lower latency); ML-DSA-65 (recommended) |
CNSA 2.0 note: U.S. National Security Systems must use ML-KEM for key exchange and ML-DSA for signatures. SLH-DSA is not approved for NSS deployments. Commercial organizations may adopt CNSA 2.0 as a high-assurance reference baseline [8].
Why Hybrid Deployment Is the Right Model for 2026
When evaluating ML-KEM vs ML-DSA vs SLH-DSA for active deployment, NIST and leading security practitioners universally recommend hybrid cryptography — combining a post-quantum algorithm with its classical counterpart so that an attacker must break both to compromise a session.
For TLS key exchange, the recommended configuration is ML-KEM-768 combined with X25519 (designated X25519MLKEM768), natively supported by Chrome, Firefox, Edge, Brave, and Opera, and deployed by Cloudflare across billions of TLS sessions. AWS has enabled hybrid ML-KEM in its Key Management Service; Google Cloud and Microsoft Azure have published comparable roadmaps.
For digital signatures, DigiCert piloted dual-key hybrid certificates — pairing ECDSA with ML-DSA — in 2026 [9] with broader ecosystem support pending IETF standardization. The hybrid approach provides simultaneous protection against both classical and quantum adversaries, making it strictly superior to either algorithm deployed in isolation during the transition period.
💡 For more information,
→ View all Post-Quantum Security series articles here
Counter-Arguments: Four Honest Challenges to Deploying These Standards Now
- Objection: ML-KEM and ML-DSA are unproven in production — deploying them before broader battle-testing introduces more risk than it mitigates.
- Discussion: The NIST PQC evaluation process subjected these algorithms to eight years of cryptanalytic scrutiny by hundreds of researchers across more than 25 countries. [1] As of 2026, no practical vulnerability has been identified in ML-KEM or ML-DSA. The algorithms have been deployed in production at internet scale — Cloudflare and Google have processed billions of TLS sessions using hybrid ML-KEM configurations without security incidents. The comparison point is not an idealized future algorithm — it is RSA and ECC, both of which are provably vulnerable to Shor’s algorithm once a CRQC exists.
Solution: Deploy hybrid configurations (ML-KEM + X25519, ML-DSA alongside ECDSA) rather than pure post-quantum deployments. Hybrid mode ensures that any undiscovered weakness in either component does not compromise security alone.
- Objection: The larger key and signature sizes will degrade TLS performance unacceptably — particularly for high-throughput services.
- Discussion: Production data from Cloudflare’s deployment of ML-KEM-768 + X25519 hybrid TLS shows that the approximately 2 KB of additional handshake overhead introduces negligible latency in standard network conditions, and performance overhead effectively approaches zero when TLS session resumption is used. [6] For ML-DSA signatures, the 3,309-byte signature size is approximately 52 times larger than Ed25519 — but ML-DSA signs 10x faster than RSA-2048. The bandwidth overhead is a real engineering consideration; the latency overhead, for most enterprise environments, is not. Genuine constraints exist in IoT and embedded systems, which require hardware-accelerated PQC implementations.
Solution: Benchmark the specific performance impact in your environment before making architectural decisions. For TLS and VPN deployments, production evidence from Cloudflare and AWS indicates the overhead is manageable. Constrained devices require hardware-accelerated implementations.
- Objection: SLH-DSA’s enormous signature sizes — up to 49,856 bytes — make it impractical and should be excluded from migration planning.
- Discussion: SLH-DSA’s large signatures are a legitimate engineering constraint. SLH-DSA-128f (fast variant, 17,088-byte signatures) and SLH-DSA-256f (49,856-byte signatures) are genuinely impractical for high-frequency signing workflows or bandwidth-constrained protocols. [4] NIST explicitly acknowledges this: SLH-DSA is not intended as a general-purpose replacement for ECDSA in high-frequency use cases. Its primary role is as a mathematical diversity hedge for low-frequency, long-lived signatures where the independence of hash-based security assumptions justifies the size overhead.
Solution: Assign SLH-DSA to specific use cases — archival signatures, root CA signing, firmware signing, where low signing frequency makes the size overhead acceptable — rather than treating it as a universal ML-DSA replacement. ML-DSA-65 handles the majority of signature use cases.
- Objection: Organizations should wait for FN-DSA (FIPS 206 / Falcon) before finalizing their migration — it offers much smaller signatures than ML-DSA.
- Discussion: FN-DSA (Falcon) provides significantly smaller signatures than ML-DSA — roughly 16 times smaller — and is under NIST standardization as FIPS 206.[7] However, FN-DSA requires floating-point arithmetic in its implementation, which raises side-channel vulnerability concerns in environments without secure floating-point computation, including many constrained devices. NSA has noted that it appears more susceptible to implementation errors and has not approved it for NSS.[8] Waiting for FN-DSA means delaying migration without protecting against HNDL attacks occurring today.
Solution: Begin migration with ML-KEM-768 and ML-DSA-65 now — both are finalized and production-ready. Plan FN-DSA adoption once FIPS 206 is finalized, particularly for bandwidth-constrained scenarios where its compact signatures offer a genuine advantage.
Knowledge Assessment: Algorithm Selection in Practice
Knowledge Assessment Quiz: Which NIST PQC Algorithm Should You Deploy?
Q1: Your organization needs to secure TLS 1.3 key exchange on all internet-facing services. Which algorithm should you deploy first?
- A) ML-DSA-65 — the NIST-recommended digital signature standard
- B) SLH-DSA-128f — for its small public key footprint
- C) ML-KEM-768 in hybrid mode with X25519
- D) Wait for FN-DSA (FIPS 206) to finalize before any deployment
Q2: A security architect needs to sign long-lived government archive documents that must remain verifiable for 30 years, and wants protection if a flaw is later found in lattice math. Which algorithm is most appropriate?
- A) ML-KEM-1024 — the highest-security key encapsulation variant
- B) ML-DSA-87 — the highest-security lattice signature variant
- C) SLH-DSA-256s — hash-based with independent security assumptions
- D) RSA-4096 — the most widely deployed signing algorithm today
Q3: Your organization operates within the U.S. National Security Systems (NSS) framework under CNSA 2.0. Which statement is accurate regarding SLH-DSA?
- A) SLH-DSA is mandated for all NSS software signing by 2027
- B) SLH-DSA is not included in CNSA 2.0 and is not approved for NSS use
- C) SLH-DSA replaces ML-KEM for key exchange in NSS environments
- D) SLH-DSA and ML-DSA are interchangeable for all NSS use cases
Score Interpretation:
- All correct (C, C, B): Strong algorithm selection knowledge. Proceed to deployment planning using the selection matrix in Table 3 above.
- Mostly correct: Review the functional distinction between ML-KEM (key encapsulation) and ML-DSA/SLH-DSA (signatures) — these are not interchangeable.
- Incorrect: Return to ‘The Three NIST Post-Quantum Standards’ and ‘Algorithm Selection Matrix’ sections before making deployment decisions.
FAQ
Q1: What is the difference between ML-KEM and ML-DSA?
A: ML-KEM (FIPS 203) is a Key Encapsulation Mechanism — it establishes a shared encryption key between two parties, replacing ECDH in TLS handshakes and VPNs. ML-DSA (FIPS 204) is a digital signature algorithm — it authenticates the identity of a signer and verifies message integrity, replacing ECDSA in code signing and certificates. They serve entirely different cryptographic functions and are not interchangeable.
Q2: Why did NIST standardize both ML-DSA and SLH-DSA?
A: ML-DSA and SLH-DSA serve distinct strategic roles. ML-DSA is the primary signature standard — lattice-based, fast, and suitable for general-purpose use. SLH-DSA is the backup standard — hash-based with security independent of lattice mathematics. NIST recommends maintaining at least one deployed signature algorithm from each mathematical family, so that a future flaw in one family does not compromise all signature security simultaneously. The SIKE break in 2022 demonstrated the practical importance of this diversity.
Q3: Which ML-KEM parameter set should most enterprises deploy?
A: ML-KEM-768 is the recommended default for most enterprise environments, providing NIST Level 3 security roughly equivalent to AES-192. ML-KEM-1024 is appropriate for deployments subject to CNSA 2.0 requirements (U.S. National Security Systems) or where maximum security is required.
ML-KEM-512 is suitable for resource-constrained environments where Level 1 security is acceptable. All three should be deployed in hybrid mode with X25519 during the transition period.
Q4: Is SLH-DSA approved for U.S. National Security Systems?
A: No. SLH-DSA is not included in CNSA 2.0 and is explicitly not approved for any use in National Security Systems. NSS environments must use ML-KEM for key exchange and ML-DSA for signatures per the NSA’s CNSA 2.0 requirements. SLH-DSA is appropriate for commercial deployments where algorithmic diversity or specific long-lived archival use cases justify its large signature sizes.
Q5: What is hybrid cryptography, and do I need it?
A: Hybrid cryptography combines a classical algorithm (X25519 or ECDSA) with a post-quantum algorithm (ML-KEM or ML-DSA) in a single protocol, requiring an attacker to break both to compromise the session. NIST permits and recommends hybrid key exchange using ML-KEM + X25519.
All major cloud providers and browser vendors have implemented hybrid TLS configurations. Hybrid deployment is strongly recommended in 2026 because it protects against both classical adversaries today and quantum adversaries in the future, eliminating the risk of choosing the wrong single algorithm.
Q6: How does ML-DSA compare to RSA in signing speed?
A: ML-DSA-65 signs approximately 10 times faster than RSA-2048, at roughly 100 to 200 microseconds per signing operation versus 2 to 5 milliseconds for RSA-2048. Verification speed is similarly competitive.
The performance advantage of ML-DSA over RSA means that migration to post-quantum signatures, where ML-DSA replaces RSA in code-signing pipelines and authentication systems, does not introduce latency penalties — and may actually improve performance in high-frequency signing workflows.
PQC Series Overview
This article is part of the Post-Quantum Security Series — a technical collection of guides exploring cryptographic vulnerabilities exposed by quantum computing, migration strategies for organizations, and the steps required to protect sensitive data before quantum decryption becomes operationally viable.
References
- [1] NIST. Post-Quantum Cryptography FIPS Approved — FIPS 203, 204, 205. August 13, 2024. https://csrc.nist.gov/news/2024/postquantum-cryptography-fips-approved
- [2] NIST. FIPS 203 — Module-Lattice-Based Key-Encapsulation Mechanism Standard. August 2024. https://csrc.nist.gov/pubs/fips/203/final
- [3] NIST. FIPS 204 — Module-Lattice-Based Digital Signature Standard. August 2024. https://csrc.nist.gov/pubs/fips/204/final
- [4] NIST. FIPS 205 — Stateless Hash-Based Digital Signature Standard. August 2024. https://nvlpubs.nist.gov/nistpubs/fips/nist.fips.205.pdf
- [5] IBM Research. NIST’s Post-Quantum Cryptography Standards Are Here. August 2024. https://research.ibm.com/blog/nist-pqc-standards
- [6] Cloudflare Research. NIST’s First Post-Quantum Standards — What This Means for the Internet. https://blog.cloudflare.com/nists-first-post-quantum-standards/
- [7] NIST. FIPS 204 — ML-DSA Performance Benchmarks and Parameter Sets. August 2024: https://csrc.nist.gov/pubs/fips/204/final
- [8] NSA. Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) FAQ. December 2024 Ver. 2.1. https://media.defense.gov/2024/Dec/06/2003358529/-1/-1/0/CSI_CNSA_2.0_FAQ_V2.1.PDF
- [9] DigiCert. Tracking the Progress Toward Post-Quantum Cryptography. November 2024. https://www.digicert.com/blog/the-progress-toward-post-quantum-cryptography
- [10] PQCA — PQC Algorithm Performance Benchmarks 2025: https://pq-crystals.org/dilithium/index.shtml
