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 lattice-based signature scheme selected through the NIST PQC Standardization Project and is a primary replacement for ECDSA and RSA signatures. 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.
Source summary (not a direct quotation)
ML-DSA is NIST's standardized module-lattice-based scheme for generating and verifying digital signatures.
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. The international cryptographic research community analyzed the lattice-based signature submission during the NIST PQC process. ML-DSA is believed to be secure against classical and large-scale quantum attacks under its mathematical assumptions, but continued cryptanalysis and careful implementation remain necessary.
FIPS 204 Parameter Sets: ML-DSA-44, -65, and -87
FIPS 204 defines ML-DSA-44 at NIST security category 2, ML-DSA-65 at category 3, and ML-DSA-87 at category 5. Category 2 uses SHA-256 collision search as its reference; categories 3 and 5 use AES-192 and AES-256 key search respectively. Select parameters according to the applicable security policy and protocol. CNSA 2.0 specifies ML-DSA-87 for NSS; FIPS 204 does not prescribe ML-DSA-65 as a universal production default.
ML-DSA signatures are larger than ECDSA signatures. FIPS 204 specifies a 3,309-byte signature and 1,952-byte public key for ML-DSA-65. A raw ECDSA P-256 signature is 64 bytes, although protocol encoding adds overhead. These size increases affect certificates, TLS handshakes, and code-signing metadata. Evaluate them in the intended deployment context.
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 migration requires coordinated verifier and trust-store support. Root CAs sign intermediate certificates, which issue end-entity certificates. A chain may use different algorithm families at different levels; every verifier must support each signature algorithm used in the chain. Replacing trust anchors requires planning across the systems that rely on them.
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-87 for general-purpose digital signatures in National Security Systems. Validated ML-DSA is also approved for software and firmware signing; LMS and XMSS are additional approved options for those specific applications. SLH-DSA and FN-DSA are not part of CNSA 2.0. SLH-DSA is not approved for NSS use. Operators must follow CNSSP 15, applicable validation requirements, and current NSA profiles for phased migration milestones and exceptions.
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.
Source summary (not a direct quotation)
CNSA 2.0 specifies ML-DSA-87 for general-purpose NSS signatures. Validated ML-DSA is approved for all signing use cases, with LMS and XMSS also allowed for software and firmware signing. Operators must follow the applicable validation requirements and transition milestones.
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 has smaller signatures than SLH-DSA; signing performance depends on the implementation, parameter set, and workload. SLH-DSA offers a hash-based alternative where independence from lattice assumptions is valued, including supported trust-anchor and archival designs. Its security relies on multiple hash-function properties and related constructions, not collision resistance alone.
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]NISTNIST SP 1800-38 (preliminary draft)(2023)Migration to Post-Quantum Cryptography (preliminary drafts and current project guidance)
- [4]NSANSA CNSA 2.0(2024)The Commercial National Security Algorithm Suite 2.0 and Quantum Computing FAQ
- [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.