What Is ML-DSA?
ML-DSA (Module-Lattice-Based Digital Signature Algorithm) is the post-quantum digital signature standard published by NIST as FIPS 204 in August 2024. It is derived from the CRYSTALS-Dilithium algorithm submitted to the NIST PQC Standardization Project and is the primary designated replacement for ECDSA and RSA signatures in digital signature applications. ML-DSA is based on Module-LWE and Module-SIS lattice problems, which are believed to be computationally hard for both classical and quantum computers.
Digital signatures are used throughout modern security infrastructure: X.509 certificates bind public keys to identities and are signed by certificate authorities; TLS server authentication relies on certificate signatures; code signing ensures software updates and binaries have not been tampered with; software package managers verify package integrity using digital signatures; hardware devices verify firmware authenticity using embedded verification keys. ML-DSA provides a quantum-resistant replacement for the digital signature component across all of these use cases.
“This standard specifies ML-DSA, a digital signature scheme derived from the CRYSTALS-Dilithium submission to the NIST Post-Quantum Cryptography Standardization Project.”
The Problem ML-DSA Solves
ECDSA and RSA-based signature algorithms rely on the hardness of the discrete logarithm and integer factorization problems respectively. Shor's algorithm running on a sufficiently large quantum computer can solve both problems efficiently, making classical digital signatures verifiable-forgeable by a quantum adversary. An attacker with a capable quantum computer could forge certificate signatures, impersonate certificate authorities, or sign malicious code with a valid-looking signature that passes classical verification.
The threat to digital signatures is different from the HNDL threat. Signature forgery requires a quantum computer at attack time, not during the signature's creation. However, long-lived trust anchors such as root certificate authority certificates, which are embedded in operating systems and browsers and valid for decades, are at particular risk if a capable quantum computer arrives before they expire. Migrating root CAs, intermediate CAs, and code signing infrastructure to ML-DSA should be prioritized alongside key exchange migration.
Mathematical Foundation: Module-LWE and Module-SIS
ML-DSA's security is based on two related lattice problems: Module Learning With Errors (Module-LWE) and Module Short Integer Solution (Module-SIS). The security of signature schemes requires both a hardness assumption for private key recovery and a hardness assumption for signature forgery. In ML-DSA, Module-LWE underlies the difficulty of recovering the private key from the public key, while Module-SIS underlies the difficulty of forging a valid signature without knowledge of the private key.
Both Module-LWE and Module-SIS are structured lattice problems with well-studied connections to worst-case lattice hardness. The international cryptographic research community subjected CRYSTALS-Dilithium to extensive analysis during the NIST PQC process, and no quantum algorithms are known that solve Module-LWE or Module-SIS significantly faster than the best classical algorithms at the parameter sizes used in FIPS 204. This analysis forms the basis of NIST's confidence in ML-DSA as the primary post-quantum signature standard.
FIPS 204 Parameter Sets: ML-DSA-44, -65, and -87
NIST FIPS 204 defines three parameter sets targeting different security levels. ML-DSA-44 targets NIST security level 2, providing security at least as hard as AES-128 against classical adversaries and quantum adversaries alike. ML-DSA-65 targets NIST security level 3, corresponding to AES-192 security strength. ML-DSA-87 targets NIST security level 5, corresponding to AES-256 security strength. NIST recommends ML-DSA-65 for most production deployments as the best balance of security margin and signature size.
ML-DSA signatures are larger than ECDSA signatures. An ML-DSA-65 signature is approximately 3,293 bytes compared to an ECDSA P-256 signature of approximately 64 bytes. Public key sizes are also larger: an ML-DSA-65 public key is approximately 1,952 bytes versus 64 bytes for ECDSA P-256. These size increases affect certificate sizes, TLS handshake message sizes, and code signing metadata volumes. Organizations should evaluate size impacts in their specific deployment contexts during migration planning.
How ML-DSA Signing and Verification Works
ML-DSA involves three operations: key generation, signing, and verification. Key generation produces a public key and a private key pair. Signing takes the private key and a message (or message hash) and produces a signature using a technique called the Fiat-Shamir with Aborts paradigm, which is central to how lattice-based signature schemes are constructed. The signing process introduces controlled randomness and uses a rejection sampling step to ensure the signature does not leak information about the private key.
Verification takes the public key, the message, and the signature, and deterministically checks whether the signature is valid for the message under the given public key. ML-DSA verification is fast and computationally lightweight. Unlike ECDSA, which had a well-known implementation vulnerability where weak randomness in the nonce led to private key recovery, ML-DSA's design is more robust against randomness failures because the abort-and-retry signing mechanism is inherently resistant to weak randomness in the same way ECDSA was not.
ML-DSA in Code Signing
Code signing is one of the highest-priority ML-DSA migration targets. Software update mechanisms, package managers, application stores, and binary distribution systems all rely on digital signatures to verify that software has not been tampered with in transit or at rest. If an adversary with quantum computing capability can forge code signing signatures, they can distribute malicious software that passes signature verification, potentially compromising every system that accepts signed software from the compromised signing infrastructure.
Code signing migration to ML-DSA requires updating signing infrastructure the hardware security modules (HSMs) or software signing services that hold signing private keys to support ML-DSA key generation and signing. Verifying infrastructure build systems, deployment pipelines, package managers, and operating system update mechanisms must be updated to accept and verify ML-DSA signatures. Hybrid signing (signing with both ECDSA and ML-DSA simultaneously) during the migration period allows a phased rollout while maintaining backward compatibility.
ML-DSA in PKI and Certificates
X.509 certificate infrastructure is the most complex ML-DSA migration target due to the hierarchical nature of PKI trust chains and the wide distribution of trust anchors. Root CA certificates are embedded in operating systems, browsers, and other trust stores, and changing them requires coordinated updates across enormous software ecosystems. Intermediate CA certificates signed by root CAs are used to issue end-entity certificates. Every certificate in the chain must use a mutually consistent algorithm family for chain verification to succeed.
ETSI TS 119 312 addresses cryptographic suite requirements for electronic signatures and certificates in European contexts and is being updated to incorporate post-quantum algorithms. The IETF LAMPS (Limited Additional Mechanisms for PKIX and SMIME) working group has developed specifications for incorporating post-quantum algorithms into X.509 certificates and PKIX infrastructure. Migration strategies for PKI typically involve establishing new post-quantum root CAs running in parallel with classical root CAs, then progressively migrating intermediate CAs and end-entity certificates to the new hierarchy.
ML-DSA in Software Updates and Firmware Signing
Over-the-air (OTA) software update mechanisms for mobile devices, IoT devices, automotive systems, and industrial control equipment rely on digital signatures to verify update authenticity. Firmware signing for embedded systems uses signature verification to prevent unauthorized firmware from being installed. These use cases require quantum-resistant signatures because devices may have operational lifetimes of ten to twenty years or more well within the window where quantum hardware capable of signature forgery could become available.
Firmware signing migration is particularly challenging because the verification public keys are often embedded in device hardware in ROM, eFuses, or Secure Boot registers and cannot be updated without hardware replacement or specialized factory re-provisioning. New device designs should use ML-DSA or SLH-DSA for firmware signature verification from the outset. For existing deployed devices, the verification key embedded in hardware constrains the available migration path: hybrid signatures (verifiable by both the legacy classical verifier and a new post-quantum verifier in the update mechanism) may provide a transition path.
ML-DSA in General Authentication
Beyond PKI and code signing, ML-DSA applies to any authentication system that uses digital signatures. This includes JWT (JSON Web Token) signing in API authentication, SAML assertions in enterprise SSO, document signatures in legal and financial workflows, and blockchain transaction signing. Each of these contexts presents different performance and size requirements that should be evaluated during migration planning.
For high-volume API authentication using signed JWTs, ML-DSA-65 signature sizes are significantly larger than ECDSA signatures, which increases token size in HTTP headers or request bodies. Organizations with API performance requirements should profile ML-DSA signing and verification throughput under expected load and evaluate whether the signature size increase materially affects latency or bandwidth budgets. In most cases, the impact is manageable; in extreme high-volume scenarios, caching token verification results or using shorter-lived tokens to avoid signature verification bottlenecks may be appropriate.
NSA CNSA 2.0 Requirements for ML-DSA
NSA CNSA 2.0 specifies ML-DSA as the required post-quantum digital signature algorithm for National Security Systems, supplemented by SLH-DSA for specific long-term trust anchor use cases. CNSA 2.0 establishes migration timelines for NSS, with requirements that vary by system type and use case. Software and firmware signing should transition to CNSA 2.0 signature algorithms according to the timelines specified in the advisory for the relevant system categories.
For organizations subject to CNSA 2.0 requirements, ML-DSA-87 (the highest security level) is typically specified for NSS applications. Commercial organizations not subject to CNSA 2.0 have more flexibility and can use ML-DSA-65 for most production use cases, reserving ML-DSA-87 for the highest-sensitivity signing contexts. The CNSA 2.0 advisory should be reviewed directly for the authoritative algorithm and timeline requirements for National Security System contexts.
“NSA requires the use of CRYSTALS-Dilithium [ML-DSA] for digital signatures to protect National Security Systems, with specific algorithm parameters and migration timelines defined in the CNSA 2.0 suite requirements.”
When to Use ML-DSA vs. SLH-DSA
ML-DSA and SLH-DSA are both NIST-standardized post-quantum digital signature algorithms with different mathematical foundations and performance profiles. ML-DSA is the primary recommendation for most production signing workloads due to its faster signing performance and smaller signatures relative to SLH-DSA. SLH-DSA is the preferred choice for applications where algorithm independence is valued specifically trust anchors, root certificate authorities, and long-term archival signatures because its security depends only on hash function collision resistance rather than lattice problems.
The two algorithms should be seen as complementary rather than competing. A typical deployment uses ML-DSA for high-volume, performance-sensitive signing such as TLS certificate verification, code signing pipeline throughput, and API authentication, while using SLH-DSA for root trust anchors and firmware signing roots where signing frequency is low but trust longevity is paramount. Where algorithm diversity is required, using both ML-DSA and SLH-DSA in a hybrid signing scheme provides the strongest available protection.
Migration Path from ECDSA and RSA Signatures
Migrating from ECDSA or RSA signatures to ML-DSA follows a phased approach. The first phase establishes ML-DSA key generation and signing capability in the signing infrastructure typically HSMs or cloud-based signing services and validates interoperability with target verification environments. During this phase, signing may occur with both ECDSA and ML-DSA (dual signing) to maintain backward compatibility while testing ML-DSA verification paths.
The second phase extends ML-DSA signing to production signing pipelines and deploys ML-DSA verification support to receiving systems. The third phase, once ML-DSA verification is universal in target environments, removes ECDSA signing from the production pipeline and operates with ML-DSA alone. For PKI migration, this process involves establishing new ML-DSA certificate hierarchies, cross-signing between classical and post-quantum hierarchies during the transition, and progressively retiring classical certificate chains as ML-DSA chains achieve sufficient ecosystem support.
References
- [1]NISTNIST FIPS 204(2024)Module-Lattice-Based Digital Signature Standard (ML-DSA)
- [2]NISTNIST FIPS 203(2024)Module-Lattice-Based Key-Encapsulation Mechanism Standard (ML-KEM)
- [3]
- [4]NSANSA CNSA 2.0(2022)Commercial National Security Algorithm Suite 2.0
- [5]CISACISA/NSA/NIST Joint Guidance(2023)Quantum-Readiness: Migration to Post-Quantum Cryptography
- [6]IETFIETF PQUIP WG(2022)Post-Quantum Use In Protocols Working Group
- [7]ETSIETSI TS 119 312(2023)Electronic Signatures and Infrastructures (ESI); Cryptographic Suites
Related Guides
Complete Guide to Post-Quantum Cryptography
A comprehensive reference covering why classical public-key cryptography is being replaced, the NIST-standardized algorithms (ML-KEM, ML-DSA, SLH-DSA), the harvest-now decrypt-later threat, and how to plan and execute a cryptographic migration program.
What Is Harvest Now Decrypt Later?
Harvest-now, decrypt-later (HNDL) is the most immediate cryptographic risk requiring action before quantum computers exist at scale. This guide explains how HNDL attacks work, what data is most exposed, and why cryptographic migration cannot wait.
ML-KEM Explained
ML-KEM (NIST FIPS 203) is the primary post-quantum key encapsulation mechanism, replacing RSA and ECDH in TLS, VPNs, and SSH. This guide explains how it works, its parameter sets, hybrid deployment, and migration from ECDH.