QUANTUM INTEL6
[Quantum Computing]Google demonstrates 1,000-qubit processor milestone
CNSA 2.0178d
Q-Day~1274d
BLOG / STANDARDS

ML-KEM vs ML-DSA: What's the Difference?

Understanding the two core NIST post-quantum standards — ML-KEM for key exchange and ML-DSA for digital signatures.

PQ
PQSCORE TEAM · JUN 2, 2026 · 4 MIN READ
FIG.02 — NIST FIPS 203 / 204

When implementing post-quantum cryptography, you'll encounter two primary standards: ML-KEM and ML-DSA. While both protect against quantum attacks, they serve fundamentally different purposes in your cryptographic infrastructure. Understanding these differences is crucial for proper implementation and compliance with emerging regulations.

What Are ML-KEM and ML-DSA?

ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism) is the NIST-standardized algorithm for key exchange, finalized as FIPS 203 on August 13, 2024. It's the evolution of CRYSTALS-Kyber, designed to establish shared secrets between parties securely.

ML-DSA (Module-Lattice-Based Digital Signature Algorithm) is the standardized digital signature algorithm, published as FIPS 204 on the same date. It evolved from CRYSTALS-Dilithium and provides authentication and integrity verification.

Both algorithms rely on the hardness of lattice problems, which remain difficult even for quantum computers. However, their mathematical structures and operational characteristics differ significantly.

Key Exchange vs Digital Signatures: Core Functions

The fundamental distinction lies in their cryptographic roles:

ML-KEM handles key exchange. When you establish a TLS connection or encrypt data, ML-KEM creates a shared secret between two parties without transmitting the secret itself. Think of it as a secure method to agree on an encryption key that both parties can use for subsequent communication.

ML-DSA provides digital signatures. When you need to verify authenticity or ensure data hasn't been tampered with, ML-DSA creates a mathematical proof that only the holder of a private key could have produced. This includes signing certificates, software packages, or any data requiring authentication.

In a typical TLS 1.3 handshake, you might use both: ML-KEM for establishing the session key and ML-DSA for authenticating the server's certificate.

Performance and Size Characteristics

The algorithms have distinct performance profiles that affect deployment decisions:

ML-KEM offers relatively compact key and ciphertext sizes. ML-KEM-768, the most commonly deployed variant, has a public key of 1,184 bytes and produces ciphertexts of 1,088 bytes. Key generation and encapsulation operations are fast, making it suitable for high-frequency operations like TLS handshakes.

ML-DSA signatures are larger but still practical. ML-DSA-65 produces signatures around 3,293 bytes with public keys of 1,952 bytes. While signature generation is reasonably fast, verification is even faster — an important consideration for systems that verify signatures more often than they create them.

For comparison, classical RSA-2048 signatures are 256 bytes, while ECDSA P-256 signatures are just 64 bytes. The size increase is a necessary trade-off for quantum resistance.

Implementation Requirements and Standards

Different compliance frameworks specify different requirements for each algorithm:

CNSA 2.0 mandates ML-KEM-1024 and ML-DSA-87 (the highest security levels) for new National Security Systems acquisitions by January 1, 2027. This requirement applies to both key exchange and signature operations in classified environments.

Commercial deployments typically use ML-KEM-768 and ML-DSA-65, balancing security with performance. These variants appear in hybrid configurations with classical algorithms during the transition period.

European regulations under NIS2 and DORA don't specify particular algorithms but require organizations to prepare for post-quantum transitions. The EU's quantum roadmap suggests initial deployments by end-2026, with broader adoption by 2030.

Hybrid Modes and Migration Strategies

During the transition to post-quantum cryptography, you'll often deploy these algorithms in hybrid mode:

For key exchange, combinations like X25519+ML-KEM-768 provide security against both classical and quantum adversaries. This approach is already supported in OpenSSL 3.5.0 (released April 8, 2025) and major browsers.

For signatures, hybrid modes are less common but may combine ML-DSA with ECDSA or RSA during migration periods. Certificate authorities are beginning to issue dual-signature certificates for compatibility.

The migration timeline varies by sector. DORA has applied to EU financial entities since January 2025, requiring risk-based cryptographic controls (though it names no specific algorithm), while broader commercial adoption follows the post-quantum migration timeline through 2026 and beyond.

Making the Right Choice

When implementing post-quantum cryptography:

  1. Identify your use cases: Map where you use key exchange (TLS, VPNs, encrypted storage) versus signatures (certificates, code signing, document authentication)

  2. Select appropriate security levels: ML-KEM-768/ML-DSA-65 for most commercial applications, higher levels for sensitive data or regulatory requirements

  3. Plan for size constraints: Ensure your infrastructure can handle larger keys and signatures, particularly for embedded systems or bandwidth-limited environments

  4. Test hybrid configurations: Start with hybrid modes to maintain compatibility while gaining operational experience

Both ML-KEM and ML-DSA are essential components of a quantum-resistant infrastructure, but they're not interchangeable. Understanding their distinct roles ensures you implement the right algorithm for each cryptographic operation.

Scan your domain free with PQScore →

PREVIOUS
NIS2 and DORA: What 'State-of-the-Art Cryptography' Actually Requires
NEXT
How to Enable X25519MLKEM768 in Nginx and OpenSSL 3.5