Is ML-DSA Quantum Safe?

ML-DSA is a NIST-standardized post-quantum digital-signature algorithm.

How ML-DSA Works

ML-DSA (Module-Lattice-Based Digital Signature Algorithm), formerly CRYSTALS-Dilithium, is a post-quantum digital signature scheme standardized by NIST as FIPS 204 in August 2024. It replaces RSA and ECDSA for signing and verification operations. ML-DSA is based on the Module Learning With Errors (MLWE) problem, the same lattice-based mathematical foundation as ML-KEM.

ML-DSA uses structured module-lattice problems, polynomial arithmetic, and SHAKE-based components defined by FIPS 204. Implementations must follow the standard exactly, including input handling, randomness or hedging mode, context, encoding, and rejection behavior.

FIPS 204 defines ML-DSA-44, ML-DSA-65, and ML-DSA-87, aligned with NIST security categories 2, 3, and 5. Categories are comparison targets, not direct bit-security claims or universal deployment recommendations; use the final FIPS encoding sizes and the applicable profile.

Quantum Vulnerability Explained

No practical quantum attack is known against the standardized ML-DSA parameter sets. Cryptanalytic estimates evolve, and implementation failures, side channels, randomness, fault behavior, validation, and protocol composition remain separate risks.

ML-DSA-65 targets NIST security category 3. The category must not be converted into a universal 2¹⁹² classical or 2⁹⁶ quantum break estimate.

ML-DSA received extensive public cryptanalysis during NIST standardization. Continue to track NIST errata, validation guidance, cryptanalytic results, and implementation advisories rather than treating standardization as a permanent guarantee.

Migration Path

ML-DSA is an algorithmic migration target for signatures, but deployment requires an approved application profile:

TLS certificates: Track current certificate and TLS signature-profile standards plus relying-party support. An ad hoc dual signature does not automatically provide compatibility or a defined security property.

Code signing: Select ML-DSA only when the signing format, verifier ecosystem, hardware boundary, policy, and validation program support the chosen parameter set.

Document signing: Long-term validity also depends on timestamps, revocation evidence, renewal, archival validation, law, and the container profile; an algorithm alone does not establish non-repudiation.

SSH authentication: Do not forecast support. Verify the exact upstream release, distribution build, signature profile, and both endpoint configurations.

Implementation support

Verify the exact library or cryptographic module release, provider, validation status, enabled parameter sets, API behavior, hardware boundary, and deployment policy from current primary documentation.

Implementation Considerations

• Larger encodings than common classical signatures; measure the final FIPS encoding, container, certificate chain, and transport behavior used by the exact profile
• Performance depends on implementation, hardware, module boundary, message size, batching, and side-channel protections; benchmark the production-equivalent path
• FIPS 204 defines deterministic and hedged signing behavior; follow the approved mode and randomness requirements exactly

Industries at Risk

Signature migration is application- and profile-specific; ML-DSA is not automatically the selected algorithm for every RSA or ECDSA use:

Software supply chains should verify each signing format, trust root, verifier population, update path, hardware boundary, and current vendor roadmap from primary documentation.

Financial services use different signature systems under different legal and technical profiles. ML-DSA alone does not guarantee non-repudiation or establish a universal record-retention period.

Healthcare should derive signature, evidence, and retention requirements from the actual workflow, law, contracts, and risk analysis. HIPAA does not impose a universal 50-year medical-record period or mandate ML-DSA.

Government and legal systems require profile, identity, timestamp, revocation, archival, and legal analysis. FIPS 204 standardization does not by itself establish legal enforceability.

Timeline

• August 2024: NIST published FIPS 204, making ML-DSA an official standard.
• Implementation status: Verify current library, module-validation, protocol, hardware, and provider support for the exact profile.
• Certificate status: Verify current standards, CA policy, trust-store, and relying-party support; no generic issuance window is asserted.
• CNSA 2.0 scope: ML-DSA-87 is selected for NSS, with staged milestones through 2031 unless otherwise noted.
• 2035 draft horizon: NIST IR 8547 proposes federal transition horizons for affected classical signatures; it does not establish ML-DSA as a universal default.

Select ML-DSA only through a supported, approved application profile and set the deployment date from measured risk, interoperability, validation, key-management, and rollback evidence.