ML-DSA and PQ Signing: What You Need to Know

ML-DSA stands for Module-Lattice Digital Signature Algorithm. It’s a digital signature method designed to stand up against quantum computers, which are expected to break most traditional cryptography in the near future. ML-DSA is built on lattice-based math, specifically, something called module lattices, which are known to be tough problems for both classical and quantum machines to solve.
If you’ve heard of CRYSTALS-Dilithium, ML-DSA is basically its standardized version. It’s now officially recognized by NIST as part of the post-quantum cryptography standards. In simpler terms, ML-DSA lets you sign and verify data (like documents, code, or certificates) in a way that should stay secure even when quantum computers get better.
The problem with current digital signature algorithms, like RSA or ECDSA, is that they rely on math problems that quantum computers can solve quickly. This means that when quantum machines become powerful enough (and they’re getting there), they could forge signatures, impersonate people, or break into systems that were thought to be secure. Post-quantum signature schemes are designed to stay safe even if an attacker has a quantum computer. They don’t rely on factoring large numbers or elliptic curve math.
Instead, they’re based on harder problems that quantum computers can’t easily crack, at least with everything we know today. This shift is all about staying a step ahead and keeping systems secure for the long run.
Back in 2016, NIST kicked off a big project to find and approve cryptographic algorithms that could handle the quantum future. After several rounds of testing, scrutiny, and feedback from the global crypto community, they picked a few algorithms to move forward with. ML-DSA (formerly CRYSTALS-Dilithium) was one of them. In August 2024, NIST published ML-DSA under the name FIPS 204, making it one of the go-to digital signature schemes for the post-quantum era. That makes ML-DSA a solid choice for anyone building new security tools or upgrading old ones so they’re ready for the quantum shift.
Digital signatures are kind of like handwritten signatures, but for data. When someone signs a document or a piece of code digitally, it proves that the data came from them and hasn’t been tampered with. This is done using a pair of cryptographic keys: one private (kept secret) and one public (shared with others). You sign something with your private key, and others can check it using your public key.
They’re used everywhere for software updates, secure emails, digital certificates, and even in blockchain transactions. Without digital signatures, trust on the internet would basically fall apart.
RSA and ECDSA are the usual suspects when it comes to digital signatures today. They’ve been around for a while and are built on mathematical problems that are easy to compute in one direction but hard to reverse, like factoring big numbers (RSA) or solving elliptic curve equations (ECDSA).
The problem? These systems were designed with regular computers in mind. Their security depends on certain problems being time-consuming to solve with classical methods. But when quantum computers get stronger, the math behind RSA and ECDSA becomes easy to break, meaning someone could forge signatures or decrypt things they shouldn’t be able to.
Another issue is size and speed. RSA keys and signatures can get bulky, which isn’t great for systems with limited storage or bandwidth. ECDSA is smaller and faster, but still breaks down in the face of a quantum attacker.
Quantum computers don’t just make things faster; they change the game. Algorithms like Shor’s make it possible to break RSA and ECDSA in a reasonable amount of time. That means if someone stores your signed data today and gets access to a quantum computer tomorrow, they could forge your signature and pretend it came from you.
Even though we don’t have huge, stable quantum computers yet, the concern is real enough that security agencies are already pushing for alternatives. The idea is to switch to new digital signature methods that can hold up when quantum tech becomes practical.
Lattice-based cryptography is one of the most promising replacements. Instead of relying on number factoring or curve math, it’s based on geometric shapes made up of grid-like points in space, called lattices.
The tricky problem here is finding the shortest or closest vector in one of these lattices. Sounds simple, but it turns out to be really hard, even for quantum computers. That’s what makes it a strong foundation for post-quantum cryptography.
ML-DSA uses a specific type of lattice structure called module lattices, which gives a good balance between speed, size, and security. It’s not just theoretical lattice-based methods that have been tested for years and are now being built into standards and real-world systems.
ML-DSA didn’t appear out of thin air. It’s actually the official version of CRYSTALS-Dilithium, which was a front-runner in NIST’s post-quantum cryptography project. Researchers built Dilithium using lattice-based math, and it stood up well through years of analysis and public testing.
After several rounds of evaluations, tweaks, and feedback, NIST finalized the design and renamed it ML-DSA (short for Module-Lattice Digital Signature Algorithm). This version was published as FIPS 204 in 2024. So, when people talk about ML-DSA, they’re basically referring to a polished, standardized version of Dilithium with the same core design.
ML-DSA stands out for a few reasons:
Put simply, ML-DSA gets the job done without being overly complex or heavy.
ML-DSA was designed with a few things in mind:
All of these choices were made to strike a balance, something strong enough to survive the quantum shift, but still practical to roll out in real systems.
Key generation in ML-DSA is pretty straightforward once you understand the basics of lattice math. The idea is to generate a public key and a private key that match up in a way that only the private key can create valid signatures.
Behind the scenes, it uses randomly chosen polynomials and some noise (yes, randomness plays a big role here) to build a small linear equation. Your private key is made up of secret values that fit the equation, and your public key is what someone would get if they only saw the final result without knowing the inputs. Because it’s built on hard lattice problems, reversing the process (from public key back to private key) isn’t doable, even with a quantum computer.
Signing a message with ML-DSA involves a few steps:
This retry step is important as it helps the algorithm avoid leaking any hints about the private key.
Verifying a signature is where the public key comes into play. You hash the message again (along with parts of the signature) and check if the results line up with what’s expected based on the public key.
You’re basically checking: “Would this signature have come out of the system if the person signing had the correct private key?”
If it passes the test, the signature is valid. If not, it’s rejected. It’s fast and doesn’t need any private info, so it can be used anywhere, browsers, servers, embedded devices, etc.
The “ML” in ML-DSA stands for Module Lattice, which is a slightly optimized version of the general lattice structure. A lattice, in simple terms, is a grid of points in space created by linear combinations of vectors.
Module lattices give you stronger security than plain lattices, but with less of a hit on performance. They also allow for more compact key and signature sizes without making the math too complicated. Think of it as a smart trade-off between speed, size, and safety.
ML-DSA leans heavily on SHAKE-128 and SHAKE-256, which are two extendable-output functions (XOFs). Unlike regular hash functions that give a fixed-size output, XOFs can be stretched to whatever length you need.
In ML-DSA, these are used for:
They help keep the algorithm consistent and secure without needing lots of different hashing tools. Plus, they’re efficient, which keeps performance in check.
ML-DSA comes in three levels – ML-DSA 44, ML-DSA 65, and ML-DSA 87. Each one targets a different NIST security level, which basically means how much an attacker would need to break it, even with a quantum computer. The higher the level, the stronger the protection, but it also means bigger keys and slower performance.
Let’s break them down:
This is the lightest version of the three and is meant for systems that need good security but don’t want to carry too much overhead. Think IoT devices or embedded systems that have limited memory or processing power.
It’s a solid choice when you want post-quantum protection but need to keep things small and snappy.
This version bumps up the security to NIST Level 3. It’s a middle ground option that is still fairly compact, but with stronger defences.
If you’re building something that needs a higher level of assurance, like financial applications or public sector software, then this might be the sweet spot.
This is the strongest option, designed for high-security use cases like government systems, critical infrastructure, or long-term protection of sensitive data.
It’s heavier, but it’s still built for scenarios where breaking the signature scheme just isn’t an option.
Here’s the deal — stronger security means bigger keys and signatures. That’s just how the math works.
So, depending on your needs —speed, storage, or strength —you can select the right version of ML-DSA that suits your case. It’s not about “one-size-fits-all”, but more like picking the right tool for the job.
Performance-wise, ML-DSA holds up pretty well, especially when compared to other post-quantum options.
In general, verification is faster than signing, and both are fast enough for everyday use. Even on resource-limited systems, the delays are barely noticeable.
Here’s an approximate idea (using software-only implementations):
Operation | ML-DSA 44 | ML-DSA 65 | ML-DSA 87 |
---|---|---|---|
Key Generation | ~0.15 ms | ~0.22 ms | ~0.33 ms |
Sign | ~0.35 ms | ~0.45 ms | ~0.65 ms |
Verify | ~0.08 ms | ~0.12 ms | ~0.19 ms |
ML-DSA is pretty friendly when it comes to resource usage:
Overall, ML-DSA strikes a good balance; it’s secure enough for post-quantum use, but it won’t kill your battery or max out your CPU. That makes it pretty usable across laptops, servers, and even some IoT devices.
If you’re working with Public Key Infrastructure (PKI), ML-DSA can slide in where digital signatures are needed, like for certificates, CRLs, OCSP responses, or code signing.
You’d basically swap out your current signing algorithm (like RSA or ECDSA) with ML-DSA while keeping the rest of your PKI setup mostly the same. Certificate Authorities (CAs) would need to support the new signature algorithm, and clients would need to understand it, but the core process stays familiar: generate key pair → sign with private key → verify with public key.
Support for ML-DSA in X.509 certificates is something being worked on as part of post-quantum standardization, so it’s not plug-and-play just yet, but the pieces are falling into place.
Software and firmware updates are prime targets for attackers, so digital signatures are critical here. ML-DSA can be used to sign update packages in a way that holds up against quantum attacks.
The larger signature size might mean tweaking how things are stored or transmitted (especially for over-the-air updates), but it’s totally doable. For vendors who plan to support devices 10–15 years into the future, adding post-quantum signatures like ML-DSA is a good move.
And unlike some post-quantum schemes that are really slow or massive in size, ML-DSA keeps things relatively practical.
CMS (Cryptographic Message Syntax) is used in stuff like S/MIME, time-stamping, and digital document signing. ML-DSA can be added to CMS by defining new algorithm identifiers and encoding rules.
Once that’s in place, you can use ML-DSA to sign emails, documents, or pretty much any kind of digital message just like you’d do with RSA or ECDSA today. It’s all about making sure the software that parses and validates these CMS structures knows what to do with an ML-DSA signature.
So, if you’re working on a standard or product that uses CMS, adding ML-DSA is mostly about updating support for the new algorithm and handling the bigger key and signature sizes.
Using ML-DSA in smart cards and HSMs (Hardware Security Modules) is one of the more interesting integration paths. These are places where private keys need to stay locked down, and operations must be quick and efficient.
ML-DSA’s relatively small key sizes (compared to other PQC schemes) make it easier to fit into the limited storage space of a smart card. And since signing is fast enough, ML-DSA could realistically work within the speed limits of contactless or embedded secure elements.
For HSMs, the bigger challenge is updating firmware to support lattice math and SHAKE functions. But once that’s handled, ML-DSA can be treated just like any other signing algorithm: load the key, perform the operation, and return the signature.
ML-DSA isn’t the only post-quantum signature scheme out there. Two other big names in the game are FALCON and SPHINCS+. Each has its own trade-offs, quirks, and sweet spots. Let’s break them down.
FALCON is also lattice-based like ML-DSA, but it uses a different math trick called NTRU lattices and relies on floating-point arithmetic, yep, the kind you see in your calculator.
In short, FALCON is great for compact signatures if you’ve got a safe and precise implementation. ML-DSA is friendlier to developers and less risky on the side-channel front.
SPHINCS+ is a whole different story. It’s not based on lattices, it’s based on hash functions, which are about as well-understood and simple as cryptographic tools get.
SPHINCS+ is often the “safe fallback” because of its conservative design. But ML-DSA offers a much more balanced trade-off for most practical applications.
Here’s a quick side-by-side look:
Metric | ML-DSA 44 (L2) | FALCON 512 (L1) | SPHINCS+ 128s(L1) |
---|---|---|---|
Public Key Size | ~1.3 KB | ~0.9 KB | ~32 bytes |
Private Key Size | ~2.8 KB | ~1.3 KB | ~64 bytes |
Signature Size | ~2.4 KB | ~666 bytes | ~8 KB |
Key generation speed | Fast | Fast | Slow |
Sign speed | Fast | Medium | Very Slow |
Verify speed | Very Fast | Fast | Medium |
Security Basis | Lattices | Lattices | Hash-based |
Ease of Use | Simple | Tricky (floating-point) | Simple but large |
In summary:
ML-DSA has been officially standardized by NIST under FIPS 204. This is a pretty big deal; it means ML-DSA is now part of the U.S. government’s approved list of digital signature algorithms built to handle the quantum threat.
FIPS 204 lays out the details of the algorithm, including:
It also defines test vectors and formats to ensure implementations behave consistently. If you’re building or validating software that uses ML-DSA, FIPS 204 is the go-to spec.
In short, FIPS 204 is the official recipe book for ML-DSA.
The clock is ticking on quantum readiness. NIST has made it clear: by the early 2030s, cryptographic systems should be post-quantum secure.
While that might sound far off, building and rolling out changes, especially in big, slow-moving environments like government, finance, or healthcare, takes years. That’s why 2025–2027 is the soft starting point for planning and pilot deployments.
Here’s the general recommendation:
Basically, don’t wait until 2029 to panic.
The US government, through the Office of Management and Budget (OMB) and NSA’s CNSA 2.0 guidelines, has laid out a clear post-quantum transition plan.
Key points:
ML-DSA fits directly into this timeline as a signature scheme approved for use under these future mandates. So, if you’re working with or selling to federal agencies or even large enterprises that follow federal guidance, ML-DSA is something you’ll want to bake into your crypto roadmap.
Getting started with post-quantum signatures can feel like a lot of new algorithms, key sizes, integration headaches, and compliance concerns. That’s where we come in.
At EC, we’ve built tools that make using ML-DSA straightforward. Our CodeSign Secure platform supports ML-DSA out of the box, along with other NIST-approved algorithms. Whether you’re signing software, firmware, documents, or certificates, we handle the technical details, so you don’t have to.
Here’s what we offer:
If your team is looking to test or roll out post-quantum signatures without building everything from scratch, we’re happy to help. You can start small, try things out, and grow from there.
ML-DSA isn’t just another post-quantum signature algorithm; it’s one of the front-runners, officially backed by NIST and designed to handle real-world use cases without making things overly complicated. It’s fast enough for high-volume signing, fits into existing systems like PKI and CMS, and avoids some of the trickier math pitfalls seen in alternatives like FALCON.
If you’re thinking about future-proofing your digital signatures, whether it’s for code, firmware, documents, or secure communications, ML-DSA is worth serious consideration.
And if you want a smooth way to get started, our code signing tool, CodeSign Secure, has built-in support for ML-DSA. It takes care of the key handling, signing process, and integration bits, so you can focus on what matters: shipping secure, quantum-ready software without headaches.
Check it out if you’re ready to sign smarter and stay ahead of the curve.