ML-DSA (Module-Lattice-Based Digital Signature Algorithm (FIPS 204))

ML-DSA is a digital signature scheme whose security rests on module lattice problems, standardized by NIST in FIPS 204. It defines three parameter sets, ML-DSA-44, ML-DSA-65 and ML-DSA-87, in increasing order of strength. NIST also standardized a hash-based alternative, SLH-DSA, in FIPS 205, with smaller public keys but larger and slower signatures.

Why it matters

To authenticate TLS connections against a future quantum attacker, certificate and handshake signatures must eventually move away from RSA and ECDSA. The obstacle is size. An ML-DSA-44 signature is 2,420 bytes, compared with about 64 bytes for an ECDSA P-256 signature, and a typical handshake carries several signatures and public keys: the leaf key, the signatures on the leaf and intermediate certificates, the CertificateVerify signature and embedded SCTs. Replacing all of them with ML-DSA adds many kilobytes to each handshake. Because authentication cannot be broken retroactively, this migration is less urgent than post-quantum key exchange with ML-KEM.

Example

Sizes in FIPS 204, and key generation with OpenSSL 3.5 or later:

Parameter set   Public key     Signature
ML-DSA-44       1,312 bytes    2,420 bytes
ML-DSA-65       1,952 bytes    3,309 bytes
ML-DSA-87       2,592 bytes    4,627 bytes

openssl genpkey -algorithm ML-DSA-65 -out mldsa65.key
openssl pkey -in mldsa65.key -pubout -out mldsa65.pub

Common misconceptions

• "Post-quantum certificates must come before post-quantum key exchange." The order is the reverse: recorded traffic can be decrypted later, but a signature only needs to resist forgery at the time it is verified.
• "ML-DSA is a drop-in replacement for ECDSA." Its keys and signatures are tens of times larger, which affects handshakes, CT logs and hardware security modules.
• "ML-DSA and ML-KEM do the same job." ML-DSA signs; ML-KEM establishes shared keys.