What Is FIPS 204?
FIPS 204 is the NIST standard for ML-DSA (Module-Lattice-Based Digital Signature Algorithm), published August 13, 2024. It is the primary NIST-standardized post-quantum algorithm for digital signatures, replacing ECDSA and RSA signatures in code signing, TLS certificates, document signing, and software update authentication.
Digital signatures provide authentication, integrity, and non-repudiation. They are used to verify that a certificate was issued by a trusted authority, that software was signed by its developer, and that a message has not been tampered with. ECDSA and RSA, which underpin most of today's signature infrastructure, are vulnerable to Shor's algorithm on a sufficiently large quantum computer. ML-DSA provides the same functionality with security believed to hold against quantum attacks.
ML-DSA is derived from the CRYSTALS-Dilithium submission to the NIST post-quantum competition. As with ML-KEM and FIPS 203, the standardized algorithm includes modifications from the original submission, so implementations should target FIPS 204 rather than any pre-standard Dilithium specification.
How ML-DSA Works
ML-DSA's security rests on two related lattice problems: the Module Learning With Errors (M-LWE) problem and the Module Short Integer Solution (M-SIS) problem. Both are believed to be hard for classical and quantum computers at the parameter sizes used in FIPS 204.
Signing takes a private key and a message and produces a signature. Verification takes a public key, the message, and the signature, and returns a boolean indicating whether the signature is valid. Unlike RSA where signing and verification times are asymmetric, ML-DSA signing and verification are both fast.
FIPS 204 specifies two signing modes. Pure mode hashes the message internally before signing. Pre-hash mode accepts an externally pre-hashed digest, which supports large messages and hardware tokens that cannot load full messages into memory. Both modes produce valid ML-DSA signatures but the modes are not interoperable with each other.
Parameter Sets
FIPS 204 defines three parameter sets. Larger parameter sets provide higher security but produce larger public keys and signatures.
ML-DSA-44
Targets NIST security category 2. Public key: 1,312 bytes, signature: 2,420 bytes. The smallest ML-DSA variant, appropriate where signature size is constrained and the lower security margin is acceptable.
ML-DSA-65
Targets NIST security category 3. Public key: 1,952 bytes, signature: 3,293 bytes. Recommended for most enterprise applications. Provides a strong security margin at manageable key and signature sizes.
ML-DSA-87
Targets NIST security category 5. Public key: 2,592 bytes, signature: 4,595 bytes. Required by NSA CNSA 2.0 for National Security Systems. Appropriate for root certificate authorities and high-assurance signing.
Use Cases
Code signing is one of the most urgent ML-DSA migration targets. Software supply chain attacks combined with harvest-now-decrypt-later risk mean that adversaries archiving signed software update packages today could forge signatures once quantum hardware matures. Migrating code signing to ML-DSA prevents this threat for new releases.
TLS certificate signatures are a second priority. X.509 certificate profiles supporting ML-DSA are being standardized in IETF working groups. Migration requires coordinating with certificate authorities to issue ML-DSA-signed certificates and updating TLS stacks and clients to validate them.
Document and email signing, software update authentication, and API authentication are additional use cases. Any application that uses RSA or ECDSA for signing should be included in the organization's cryptographic inventory and migration plan.
Implementation Considerations
ML-DSA requires updates to public key infrastructure, including certificate issuance processes, certificate stores, and validation libraries. HSMs used for signing must be updated or replaced if they are involved in certificate issuance, document signing, or code signing workflows.
Hybrid signatures, combining a classical ECDSA or RSA signature with an ML-DSA signature, are recommended during the transition. This provides backward compatibility for verifiers that do not yet support ML-DSA while adding quantum resistance for verifiers that do.
NIST IR 8547 provides transition timelines and deprecation schedules for RSA and ECDSA signatures. Organizations should monitor that document for updates as the planned phase-out dates approach.
Limitations and Tradeoffs
ML-DSA public keys and signatures are larger than ECDSA equivalents. For TLS, larger certificates increase handshake size and may require adjustments to session ticket and certificate caching. For code signing, larger signatures increase package sizes modestly but typically not to a degree that is operationally significant.
ML-DSA does not include built-in message recovery, so the full message must be provided for verification. This is the same model used by ECDSA and is supported by all standard signing workflows.
References
Frequently Asked Questions
When should I use ML-DSA versus SLH-DSA?
Use ML-DSA for general-purpose signing including TLS certificates, code signing, and API authentication. Its performance and key sizes are practical for most scenarios. Use SLH-DSA for highest-assurance contexts such as root certificate authorities and firmware signing, where its conservative security properties based only on hash functions provide extra confidence.
Can I use ML-DSA in my existing PKI?
Yes, with updates. IETF working groups are standardizing X.509 and CMS profiles for ML-DSA. Certificate authorities will need to issue ML-DSA-signed certificates, and clients will need to be updated to validate them. A hybrid transition using both classical and ML-DSA signatures in parallel is the recommended approach during this period.