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.
