Skip to main content
  1. Index/

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

ML-DSA (Module-Lattice-Based Digital Signature Algorithm), standardised as NIST FIPS 204 in August 2024, is the primary post-quantum replacement for digital signatures. It replaces ECDSA, EdDSA, and RSA PSS/PKCS#1 signatures in X.509 certificates, code signing, TLS client and server authentication, SSH, JWT signing, and any other context where a party proves possession of a private key by producing a signature that others verify with the public key. ML-DSA is derived from CRYSTALS-Dilithium, the submission that won NIST’s lattice-based signature selection, and its security rests on the Module Learning With Errors (MLWE) and Module Short Integer Solution (MSIS) problems — the same mathematical family as ML-KEM, which is significant because both algorithms can share implementation code and hardware acceleration for the underlying polynomial arithmetic (NTT, number-theoretic transform).

ML-DSA defines three parameter sets. ML-DSA-44 targets NIST security level 2 (between AES-128 and AES-192) with a 1312-byte public key, 2420-byte signature, and 2560-byte private key. ML-DSA-65 targets level 3 (roughly AES-192) with a 1952-byte public key, 3309-byte signature, and 4032-byte private key — the recommended general-purpose parameter set. ML-DSA-87 targets level 5 (roughly AES-256) with a 2592-byte public key, 4627-byte signature, and 4896-byte private key, required by CNSA 2.0 for national security systems. All three parameter sets produce deterministic signatures: like RFC 6979 ECDSA or EdDSA, the nonce is derived from the private key and message, eliminating the catastrophic private-key-recovery vulnerability that affects naively randomised ECDSA implementations. Signature generation in ML-DSA is rejection-sampled — the algorithm internally loops until it produces a signature that meets a norm bound — which means signing time is variable (typically 2–5 iterations in practice) rather than strictly constant, a mild complication for timing-sensitive implementations.

The dominant deployment challenge for ML-DSA is signature and public key size. An ML-DSA-65 signature at 3309 bytes is 50× larger than a P-256 ECDSA signature (64 bytes) and 13× larger than a 2048-bit RSA signature (256 bytes). In X.509 certificate chains carried in TLS handshakes, every certificate in the chain (leaf, intermediate, root) bears a signature from its issuer; a three-certificate chain with ML-DSA-65 signatures adds roughly 10 KB of signature data to the TLS Certificate message, compared to roughly 200 bytes for ECDSA. This is large enough to require multiple TLS records and TCP segments, affecting handshake latency and middle-box compatibility. The PKI and cert-manager migration path is to deploy a parallel ML-DSA CA hierarchy — ML-DSA-65 root CA, ML-DSA-65 intermediate, ML-DSA-65 leaf certificates — and serve it alongside the existing ECDSA hierarchy in hybrid mode during the transition, allowing clients that support ML-DSA to verify the post-quantum chain while legacy clients fall back to the ECDSA chain. During the hybrid period, code-signing pipelines should produce both an ECDSA and an ML-DSA signature over the same artifact; verifiers that understand both check the ML-DSA signature for quantum protection, while legacy verifiers check the ECDSA signature. For SBOM and OCI artifact signing via cosign, ML-DSA support follows when the underlying Sigstore libraries and the sigstore/sigstore-go SDK add FIPS 204 support.

Related

ECC (Elliptic Curve Cryptography)

Elliptic Curve Cryptography (ECC) is a family of public-key cryptographic algorithms built on the mathematics of elliptic curves over finite fields. Its security rests on the Elliptic Curve Discrete Logarithm Problem (ECDLP): given a public point Q = k × G on a curve (where G is a fixed base point and k is the private key scalar), recovering k from Q and G is computationally infeasible on classical computers. The practical advantage over RSA is dramatic key size efficiency: a 256-bit ECC key provides roughly the same classical security as a 3072-bit RSA key, because the best known classical algorithms for ECDLP (Pollard’s rho) are exponential whereas the best RSA algorithms (GNFS) are sub-exponential. This size difference has compounding benefits — smaller keys mean faster operations, smaller certificates, smaller TLS handshake messages, and lower power consumption on constrained devices. ECC is now the dominant choice for all new asymmetric cryptography deployments: TLS 1.3 mandates ECDHE for key exchange, and ECDSA or EdDSA for authentication; SSH defaults to Ed25519; code signing infrastructure increasingly uses ECDSA P-256 or Ed25519.

ECDSA (Elliptic Curve Digital Signature Algorithm)

ECDSA (Elliptic Curve Digital Signature Algorithm) is the elliptic curve analogue of DSA, standardised in FIPS 186 and the IETF, that produces digital signatures using a private key and verifies them with the corresponding public key. It is the most widely deployed signature algorithm in X.509 certificates (P-256 with SHA-256 is the default for certificate authorities issuing TLS certificates), in code signing (Authenticode, macOS, Linux package signing), in TLS 1.3 certificate authentication, in SSH host keys and user keys (though Ed25519 is increasingly preferred), and in blockchain and cryptocurrency systems. An ECDSA signature over a message m with private key d on curve with base point G produces a pair (r, s), where r is the x-coordinate of an ephemeral public key k × G and s encodes the relationship between the message hash, r, the private key d, and the nonce k. Verification requires only the public key Q = d × G and is fast; signing requires the private key and a nonce.

ML-KEM (Module-Lattice-Based Key Encapsulation Mechanism)

ML-KEM (Module-Lattice-Based Key Encapsulation Mechanism), standardised as NIST FIPS 203 in August 2024, is the primary post-quantum replacement for key encapsulation and key exchange. It replaces the role of ECDH (X25519, P-256) and RSA key transport in TLS handshakes, IPsec IKEv2 negotiations, and any other protocol that needs two parties to establish a shared secret without prior key material. ML-KEM is derived from CRYSTALS-Kyber, the submission that won NIST’s lattice-based KEM selection, and its security rests on the Module Learning With Errors (MLWE) problem: distinguishing a structured noisy linear system from a random one is computationally hard, and no efficient quantum algorithm for this problem is known. The “module” qualifier means the construction uses polynomial rings structured in a way that allows a good balance between security and efficiency, contrasting with pure LWE (larger keys, simpler structure) and NTRU (smaller keys, different structure).