How Does ML-DSA Work?
Fiat–Shamir, Rejection Sampling, Hints, and the Architecture of Post-Quantum Digital Signatures
In the previous article, we opened the black box of ML-KEM.
We saw how Module-LWE can be transformed into a practical post-quantum key-establishment mechanism through key generation, encapsulation, decapsulation, hashing, re-encryption, and implicit rejection.
Now we need to solve a completely different problem.
Suppose I download a software update.
How do I know who created it?
Suppose a server gives me a public key.
How do I know that key actually belongs to the organization I intended to contact?
Suppose a document claims to have been approved by a particular person.
How can I verify that the document has not changed since it was signed?
These are not key-establishment problems.
They are authentication and integrity problems.
And this is where digital signatures enter the story.
In the post-quantum world, one of the most important standardized solutions is:
ML-DSA — the Module-Lattice-Based Digital Signature Algorithm.
NIST standardized ML-DSA in FIPS 204 in August 2024. The algorithm is derived from CRYSTALS-Dilithium and is designed for digital signature generation and verification under a post-quantum threat model.
But ML-DSA is not simply:
“ML-KEM, but used backwards.”
Its architecture is fundamentally different.
To understand why, we first need to understand what a digital signature actually proves.
1. A Digital Signature Is Not Encryption
Encryption and signatures are sometimes discussed together because they both use cryptographic keys.
But their goals are different.
Encryption asks:
Who is allowed to read this information?
A digital signature asks:
Who authorized this information, and has it changed?
In a signature system, the signer possesses a private signing key.
The corresponding public verification key can be distributed widely.
The signer uses the private key to create a signature associated with a message.
Anyone with the public key can then check whether the signature is valid for that message.
A successful verification provides evidence that someone possessing the corresponding private key created the signature and that the signed message has not been modified.
NIST describes digital signatures as mechanisms for verifying data integrity and the identity associated with the signing key; private keys are used for generation and public keys for verification.
https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.204.pdf
This is fundamentally different from ML-KEM.
ML-KEM produces a secret shared by two parties.
ML-DSA produces a signature that can be publicly verified.
2. ML-DSA Has Three Main Operations
From the outside, ML-DSA has a simple interface.
KeyGen creates the public and private signing keys.
Sign takes the private key and a message and produces a signature.
Verify takes the public key, message, and signature and returns either valid or invalid.
FIPS 204 formally specifies these three primary algorithms as ML-DSA.KeyGen, ML-DSA.Sign, and ML-DSA.Verify.
Conceptually:
Alice generates a key pair.
She protects her private signing key.
She publishes her public verification key.
When she wants to authenticate a message, she signs it.
Bob receives:
the message,
the signature,
and Alice’s public key.
He verifies the signature.
If verification succeeds, Bob gains cryptographic evidence that the signature is consistent with the corresponding private signing key and the exact message he received.
3. What Is Inside the ML-DSA Key Pair?
The mathematical structure begins to resemble ideas we encountered in ML-KEM.
ML-DSA uses module-lattice mathematics.
During key generation, a public matrix is constructed from a compact public seed.
The signer also generates small private polynomial vectors.
Those private values are used to produce a public algebraic relationship.
Conceptually, we can think of it as:
Public Structure
combined with
Small Private Secret
and
Small Error-Like Private Structure
to produce
Public Verification Information.
The private signing key retains the short secret components required to generate valid signatures.
The public key exposes enough algebraic structure to verify signatures without exposing those private values.
The matrix itself does not need to be stored in full; FIPS 204 derives it pseudorandomly from a 256-bit public seed, which reduces public-key size.
Again, we see an important cryptographic principle:
The algorithm is public. The mathematical structure is public. Security depends on keeping specific secret information hidden and making its recovery computationally difficult.
4. The Security Foundation Is Not Exactly the Same as ML-KEM
ML-KEM and ML-DSA are both module-lattice systems.
But that does not mean their security arguments are identical.
FIPS 204 explains that lattice-signature security is related to two broad families of hard problems:
Learning With Errors
and
Short Integer Solution.
In their module variants, these become MLWE and MSIS-style problems.
More specifically, NIST states that ML-DSA’s security is based on the Module Learning With Errors problem and a specialized variant of Module-SIS called SelfTargetMSIS.
This is worth emphasizing.
ML-DSA is not simply:
“Use Module-LWE and somehow get signatures.”
A digital-signature system needs a different security structure because the adversary is trying to forge a valid proof of signing authority, not recover a shared secret from a ciphertext.
Different cryptographic goals lead to different constructions.
5. Start With an Interactive Proof
The easiest way to understand ML-DSA is not to begin with lattices.
Instead, imagine an interactive conversation between two parties.
There is a prover who knows a secret.
There is a verifier who knows the corresponding public information.
The prover wants to convince the verifier:
“I know the secret associated with this public key.”
But the prover does not want to reveal the secret itself.
A common pattern uses three steps:
Commitment
The prover generates fresh temporary secret information and sends a commitment based on it.
Challenge
The verifier responds with a random challenge.
Response
The prover combines the temporary information, the challenge, and the long-term private secret to produce a response.
The verifier then checks whether the response is mathematically consistent with the original commitment and the public key.
If everything matches, the verifier gains confidence that the prover knew the private secret.
This structure appears throughout cryptography.
ML-DSA uses a lattice-adapted version of this idea and is described by NIST as a Schnorr-like signature using the Fiat–Shamir With Aborts construction.
6. But Digital Signatures Cannot Require a Conversation
An interactive protocol creates an obvious problem.
Imagine signing a software package.
The developer cannot wait for every future user to send a random challenge before generating the signature.
The signature needs to exist once and remain verifiable later.
There may not even be a network connection between signer and verifier.
So we need to transform:
interactive proof
into
non-interactive signature.
This is where the Fiat–Shamir transform becomes important.
Instead of asking an external verifier to choose the challenge randomly, the signer generates the challenge deterministically from a cryptographic hash of the commitment and the message being signed.
Conceptually:
The signer creates a commitment.
Then computes:
Commitment + Message
→ Cryptographic Hash
→ Challenge
The verifier later performs the same hash computation.
If the signer changed either the commitment or the message, the challenge would change as well.
The interaction has effectively been replaced by cryptographic hashing.
FIPS 204 describes exactly this transformation: the verifier’s random challenge in the interactive protocol is replaced with a pseudorandom challenge derived from hashing the commitment together with the message.
7. Why Can’t We Stop There?
At first, this seems enough.
The signer has:
a temporary secret,
a commitment,
a challenge,
and a response.
The verifier can check everything using the public key.
So why does ML-DSA need anything more complicated?
Because lattice signatures introduce a subtle security problem.
The response contains a combination of:
temporary randomness
and
long-term private-key information.
If the distribution of that response depends too visibly on the private key, the signature itself may leak information about the secret.
This is dangerous.
A digital signature is public.
An attacker may collect thousands, millions, or more signatures created using the same long-term key.
Even tiny statistical biases can potentially become valuable.
FIPS 204 explicitly explains that the naive lattice response is biased in a direction related to the private values. The solution is one of the defining ideas of the scheme:
rejection sampling.
8. Sometimes the Safest Signature Is the One You Never Publish
During ML-DSA signing, the algorithm generates a candidate response.
It then asks whether that candidate falls inside carefully defined bounds.
If the candidate could reveal too much information about the private key, it is discarded.
The signer starts over with fresh temporary material.
This is why the construction is called:
Fiat–Shamir With Aborts.
Some signing attempts are intentionally aborted.
Nothing is published.
The process repeats until a safe candidate signature is produced.
NIST describes ML-DSA’s signing process as a rejection-sampling loop: an iteration either generates a valid signature or a candidate whose release could leak private-key information; unsafe candidates are rejected and the loop repeats.
That is a fascinating cryptographic idea.
The algorithm intentionally performs work that may never become externally visible.
The goal is not merely mathematical correctness.
It is to ensure that the distribution of published signatures does not reveal the long-term secret.
9. Rejection Sampling Is Not Error Handling
It is important not to confuse rejection sampling with something going wrong.
An aborted signing iteration does not mean the implementation failed.
It is normal behavior.
The algorithm was designed with rejection in mind.
In fact, the different ML-DSA parameter sets have expected signing-loop repetition counts greater than one; FIPS 204 lists expected repetitions of roughly 4.25, 5.1, and 3.85 for ML-DSA-44, -65, and -87 respectively.
So a mental model like this is more accurate:
Generate candidate.
Check candidate.
Unsafe statistical profile?
Discard it.
Try again.
Safe?
Publish the signature.
10. The Temporary Secret Must Never Be Carelessly Reused
There is another critical consequence.
The temporary signing value used to construct the commitment must not be reused in an unsafe way.
Why?
Because the response combines this temporary information with the long-term signing secret.
If the same temporary secret were used across multiple signing contexts in a way the scheme does not permit, relationships between the resulting signatures could expose information about the private key.
This phenomenon is not unique to lattice signatures.
Catastrophic failures have occurred in classical signature schemes when nonce-like signing randomness was repeated or predictable.
FIPS 204 therefore emphasizes that the commitment-generating temporary value must not be reused to sign multiple messages and must not be easily guessable.
Randomness is not a decorative implementation detail.
It is part of the security boundary.
11. ML-DSA Uses Hedged Signing by Default
FIPS 204 defines two ways of generating the temporary signing randomness.
The default is called hedged signing.
The signer combines:
a private pseudorandom value,
the message-dependent information,
and fresh randomness generated at signing time.
Why combine both?
Because each source provides a different kind of protection.
Fresh randomness helps make side-channel and fault attacks more difficult.
Private deterministic material provides protection if the fresh random-number generator behaves imperfectly.
The idea is defense in depth.
FIPS 204 also allows a fully deterministic signing variant, but NIST notes that deterministic signing can make some side-channel and particularly fault-attack mitigations more difficult. The hedged variant is the default and is sufficient for interoperability.
This is a subtle but important engineering choice.
Randomized signing can introduce dependency on the randomness source.
Deterministic signing eliminates that dependency during signature generation.
Hedged signing tries to obtain useful properties from both approaches.
12. The Message Is Bound to More Than Just Its Raw Bytes
ML-DSA does not simply drop the original message directly into every internal calculation.
The standard constructs a message representative that incorporates a hash of the public key together with the formatted message.
FIPS 204 describes this design as contributing additional security properties beyond ordinary unforgeability.
The standard also supports a context string.
A context lets an application bind a signature to a particular protocol or use case.
Conceptually, this helps separate domains.
The same message used in two different protocol contexts does not necessarily represent the same signing operation when different context strings are used.
This is a broader cryptographic principle known as domain separation.
Cryptographic objects should carry enough contextual information that values created for one purpose are not accidentally valid in another.
13. Why Does ML-DSA Need a “Hint”?
This is one of the more unusual parts of the scheme.
The signer creates a commitment based on a temporary secret.
But including the entire commitment in every signature would make signatures unnecessarily large.
ML-DSA therefore compresses information.
The public key is compressed.
The commitment representation is also reduced.
This creates a challenge for verification.
The verifier must reconstruct enough of the original commitment to recompute the same challenge, but compression and rounding mean the reconstruction is not automatically exact.
The solution is a small piece of auxiliary information called a hint.
The signer computes the hint in a way that lets the verifier recover the necessary high-order information from its approximate reconstruction.
FIPS 204 explains that the hint is included specifically so the verifier can reconstruct the signer’s rounded commitment from the response and compressed public key.
This is an elegant tradeoff.
Instead of transmitting the full large object, the signer sends:
a compressed representation,
plus just enough correction information for the verifier to reconstruct what matters.
14. What Is Actually Inside an ML-DSA Signature?
Conceptually, an ML-DSA signature contains three important components.
The first is a commitment hash.
Rather than transmitting the full commitment, the scheme includes a compact hash-derived representation associated with it.
The second is the response.
This encodes the relationship between the temporary signing value, the challenge, and the private secret.
The third is the hint.
The hint allows the verifier to reconstruct the appropriate rounded commitment information despite key compression and approximation.
FIPS 204’s signing algorithm outputs precisely these categories: the commitment hash, response, and hint.
The private key itself is never part of the signature.
15. Verification Reconstructs What the Signer Should Have Done
Now Bob receives:
the message,
the signature,
and Alice’s public verification key.
Bob does not know Alice’s private key.
So how can he check the response?
He reconstructs the mathematical relationship that should exist if the signer genuinely knew the private key.
The verifier first parses the signature.
Malformed encodings are rejected.
Then the verifier reconstructs the public module-lattice structure from the public key.
It derives the same message representative.
It extracts the challenge associated with the commitment hash.
Using the response, challenge, and public key, it computes an approximation of the signer’s commitment.
Then the verifier applies the hint.
That reconstructs the high-order commitment information required for the final check.
Finally, the verifier hashes:
the message representative
and
the reconstructed commitment.
If the resulting commitment hash agrees with the one contained in the signature — and the response satisfies the required bounds — verification succeeds.
FIPS 204 specifies this reconstruction-and-check procedure explicitly.
Notice what never happened:
Bob never learned Alice’s private signing key.
Yet he can still verify that the signature could only reasonably have been constructed by someone with the required secret information, assuming the underlying computational problems remain hard.
16. Verification Is Essentially a Consistency Test
This gives us a useful mental model.
Signing creates a carefully structured cryptographic statement.
Verification asks:
“Are the message, public key, challenge, response, hint, and reconstructed commitment all mutually consistent?”
A forged signature has to satisfy this entire structure.
An attacker cannot simply choose a random response and hope it looks plausible.
The challenge depends on the commitment and message.
The commitment reconstruction depends on the public key, response, and challenge.
The hint has strict structural constraints.
The response has size bounds.
The final hash must close the entire loop.
The components constrain one another.
That cryptographic circular consistency is what makes Fiat–Shamir signatures powerful.
17. What Security Property Is ML-DSA Trying to Provide?
NIST specifies a particularly strong forgery-resistance goal for ML-DSA:
strong existential unforgeability under chosen-message attack, usually abbreviated SUF-CMA.
Get Sunjun Hwang’s stories in your inbox
Join Medium for free to get updates from this writer.
The intuition is important.
Imagine an attacker can repeatedly ask the legitimate signer to sign messages chosen by the attacker.
Even after observing those signatures, the attacker should not be able to create any additional valid signature under the victim’s public key — including a new valid signature for a message that was already signed.
That is stronger than merely saying:
“The attacker cannot sign a completely new message.”
FIPS 204 explicitly states that ML-DSA is designed for strong existential unforgeability under chosen-message attack.
This threat model matters because public signing services are common.
An attacker may legitimately obtain many signatures.
Security has to survive that exposure.
18. Why the Signature Does Not Reveal the Secret
At a high level, the protection comes from several layers working together.
The public key hides short secret structure behind module-lattice hardness.
The temporary signing value masks the long-term private secret.
The challenge binds the commitment to the message.
Rejection sampling removes candidate responses whose distribution could expose information about the private key.
The hint provides only limited reconstruction information.
And the complete signature must satisfy strict bounds and algebraic consistency checks.
No single mechanism is doing all the work.
This is another recurring theme in modern cryptography:
Security usually emerges from composition, not from one clever trick.
19. ML-DSA Uses the NTT Too
Readers of the previous ML-KEM article may recognize another familiar component:
the Number-Theoretic Transform.
ML-DSA performs substantial polynomial arithmetic.
The NTT converts those polynomial operations into a representation where multiplication can be performed efficiently.
As with ML-KEM, this is primarily an implementation-efficiency technique rather than the fundamental hardness assumption.
FIPS 204 states that multiplication is considerably faster in the NTT representation and builds its module-lattice arithmetic around that structure.
Again:
MLWE / SelfTargetMSIS
help explain why forging should be computationally difficult.
NTT
helps perform the required polynomial arithmetic efficiently.
Security primitive and performance optimization are different roles.
20. ML-DSA Also Relies Heavily on SHAKE
ML-DSA is often introduced as a lattice-based signature.
That is correct.
But the actual standardized construction also relies heavily on symmetric cryptographic functions.
FIPS 204 uses SHAKE128 and SHAKE256 for pseudorandom expansion, hashing, sampling, and other internal operations.
So a real ML-DSA implementation is not:
just lattice arithmetic.
It is a system combining:
module-lattice hardness,
structured polynomial arithmetic,
NTT acceleration,
pseudorandom sampling,
cryptographic hashing,
compression,
rejection sampling,
and carefully controlled encoding.
Modern cryptography is layered.
21. ML-DSA Has Three Parameter Sets
FIPS 204 standardizes three ML-DSA parameter sets:
These are the standardized sizes in FIPS 204. The suffixes 44, 65, and 87 refer to dimensions of the scheme's internal matrix rather than conventional bit-length labels like RSA-2048.
The tradeoff is familiar.
Higher security parameters require more communication and storage.
And the sizes are noticeably larger than many traditional elliptic-curve signatures.
That matters for:
certificates,
firmware,
embedded systems,
network protocols,
storage formats,
and bandwidth-constrained environments.
Post-quantum migration is therefore not merely a cryptographic-theory exercise.
It changes systems engineering.
22. Why Doesn’t Everyone Just Choose ML-DSA-87?
It may seem obvious.
If ML-DSA-87 has the highest listed security category, why not deploy it everywhere?
Because security engineering is about appropriate margins, not blindly maximizing every parameter.
Larger keys and signatures create costs.
They consume bandwidth.
They increase storage.
They affect protocol messages.
They require additional computation.
A constrained device and a high-value root-of-trust system may have very different requirements.
Parameter selection therefore belongs inside a larger risk model.
Stronger is useful.
But stronger is not free.
23. ML-DSA and ML-KEM Solve Completely Different Problems
At this point, the difference between the two algorithms should be clear.
ML-KEM
answers:
“How can Alice and Bob establish shared secret material over a public channel?”
ML-DSA
answers:
“How can Alice produce publicly verifiable evidence that she signed a particular message?”
ML-KEM uses encapsulation and decapsulation.
ML-DSA uses commitment, challenge, response, rejection sampling, hints, and verification.
They share module-lattice mathematics.
But they are not interchangeable.
This is important when designing real post-quantum systems.
A secure protocol may need both.
One mechanism establishes secrets.
Another authenticates identities or objects.
24. The Public Key Still Does Not Tell You Who Alice Is
There is another subtle security point.
Suppose Bob verifies a signature successfully.
He now knows that the signature corresponds to a particular public key.
But that alone does not prove that the public key actually belongs to Alice.
Someone still has to establish the relationship:
Public Key ↔ Identity
This is normally handled by surrounding infrastructure.
Certificates.
Certificate authorities.
Public-key infrastructure.
Trusted directories.
Hardware identity systems.
Or another authenticated key-distribution mechanism.
FIPS 204 explicitly notes that signatures are most useful when a public key is properly bound to an identity and that this binding requires mechanisms beyond the signature algorithm itself.
This is an important distinction:
A signature proves consistency with a key.
A trust system tells you whose key it is.
Cryptography does not eliminate trust architecture.
It formalizes parts of it.
25. Side Channels Are Especially Important for Signatures
The signing operation touches the private key.
It also contains intermediate values influenced by that secret.
If those internal values leak through implementation behavior, the mathematical security proof may no longer matter.
Attackers may observe:
timing,
power consumption,
electromagnetic emissions,
cache behavior,
fault responses,
or other physical and software side channels.
This is particularly relevant because ML-DSA’s rejection process has internal branches.
An implementation has to ensure that its behavior does not expose sensitive information through observable patterns.
FIPS 204 warns that intermediate values may reveal private-key information and requires potentially sensitive intermediate data to be destroyed when no longer needed. It also explicitly calls out side-channel and fault-attack considerations.
Again:
Breaking the implementation may be easier than breaking the lattice problem.
26. Floating-Point Arithmetic Is Explicitly Off Limits
One detail in FIPS 204 is surprisingly concrete.
NIST states that conforming ML-DSA implementations must not use floating-point arithmetic for the specified computations because rounding behavior could produce incorrect results.
This illustrates how far cryptographic standards go beyond abstract mathematics.
A paper might describe the algorithm conceptually.
A standard has to worry about:
integer representation,
encoding,
rounding,
input length,
temporary data,
randomness generation,
and implementation consistency.
These details are part of security engineering.
27. Pure ML-DSA and HashML-DSA
FIPS 204 also defines HashML-DSA.
The difference is that HashML-DSA performs an additional pre-hashing step before the core signature operation.
Why would this be useful?
Imagine signing a very large object.
The environment containing the ML-DSA implementation may not be the most efficient place to process an enormous message directly.
Pre-hashing can allow the message to be processed using an appropriate hash mechanism before the signature operation.
But this is not simply an informal implementation trick.
HashML-DSA is domain-separated from ordinary ML-DSA so that the two modes are cryptographically distinct. FIPS 204 defines both pure ML-DSA and the pre-hash variant.
Protocol designers therefore need to know which mode they are using.
28. Post-Quantum Signatures Still Need Good Key Management
No signature algorithm can save a stolen signing key.
If an attacker obtains the private ML-DSA key, they can create signatures that verify correctly.
That is not a break of ML-DSA.
That is a key-compromise event.
So deployment still requires:
secure key generation,
protected storage,
access control,
rotation,
revocation,
backup policy,
hardware protection where appropriate,
and incident response.
This is why cryptography and key management must be treated together.
The strongest signature algorithm in the world becomes useless if its private signing key sits unprotected in a plaintext file.
29. A Standardized Algorithm Is Not the Same as a Secure System
This distinction is one of the most important lessons from the entire PQC series.
FIPS 204 standardizes an algorithm.
It does not guarantee that every application using ML-DSA is secure.
NIST explicitly states that conformance to the algorithmic standard does not guarantee the security of a particular implementation or of the wider system containing it.
A real deployment can still fail because of:
bad key management,
incorrect identity binding,
implementation bugs,
side-channel leakage,
weak randomness,
protocol misuse,
unsafe certificate handling,
or poor operational security.
Cryptography is one layer of a security architecture.
A critical layer.
But still one layer.
30. Why Rejection Sampling Is the Part I Find Most Interesting
There are many technically interesting parts of ML-DSA.
Module lattices.
Fiat–Shamir.
NTT arithmetic.
Hints.
Compression.
But rejection sampling stands out to me.
The intuitive goal of a signature algorithm is:
“Generate a valid signature.”
ML-DSA adds another requirement:
“Generate a valid signature whose public distribution does not reveal too much about how the secret key influenced its creation.”
That changes the signing mindset.
Mathematical correctness is not sufficient.
The shape of the output distribution matters.
Some candidate responses may satisfy part of the mathematical relation but are unsafe to release.
So the signer throws them away.
Cryptographic security comes partly from deciding what not to reveal.
That is a powerful idea.
31. The Whole ML-DSA Flow in One Mental Model
We can now put everything together.
Alice generates a module-lattice key pair.
Her private signing key contains small secret structures.
Her public verification key contains compressed public information derived from those secrets.
When Alice signs a message, she derives the message representative and generates temporary signing randomness.
She creates a commitment.
The commitment and message determine a challenge through hashing.
She combines the challenge with her private secret to create a candidate response.
She checks whether publishing that response and its associated values would satisfy the required security bounds.
If not, she aborts that attempt and starts again.
Once a safe candidate exists, she creates a compact hint and outputs the signature.
Bob receives the message and signature.
Using Alice’s public key, he reconstructs the commitment information implied by the response.
He uses the hint to recover the necessary high-order information.
He hashes the reconstructed commitment together with the message representation.
If the resulting challenge agrees with the signature and all bounds are valid, he accepts the signature.
Alice proved knowledge of the private signing secret.
But she never revealed it.
The Main Idea
If there is one idea I want this article to leave behind, it is this:
ML-DSA is a lattice-based proof of signing authority built around commitment, Fiat–Shamir challenge generation, bounded responses, rejection sampling, and compact reconstruction hints.
The architecture looks like this:
Module-Lattice Hardness
→ protects the private signing structure
Temporary Secret
→ masks the long-term key
Commitment
→ represents the temporary signing state
Message + Commitment
→ cryptographic hash
→ Challenge
Challenge + Private Secret + Temporary Secret
→ candidate response
Rejection Sampling
→ removes candidates that could leak information
Hint
→ enables compact commitment reconstruction
Verification
→ reconstructs the commitment and checks cryptographic consistency.
That is what is actually happening inside ML-DSA.
A Current Standards Note
As of September 2026, FIPS 204 remains NIST’s finalized standard for ML-DSA. NIST’s current FIPS 204 page includes a July 31, 2026 planning note pointing to several minor errata that are expected to be corrected in a future update or revision, so implementers should consult the current NIST publication page and associated errata rather than relying only on an older downloaded copy.
NIST is also continuing to evaluate additional post-quantum digital-signature schemes to diversify the future signature portfolio; these efforts are intended to augment, rather than replace by default, the already finalized ML-DSA and SLH-DSA standards.
That distinction matters:
An explanatory article can teach the architecture.
A production implementation should follow the current standard and its latest guidance.
What’s Next?
We now have two major pieces of NIST’s post-quantum cryptographic architecture.
ML-KEM gives us post-quantum key establishment.
ML-DSA gives us lattice-based post-quantum digital signatures.
But NIST standardized another signature system as well:
SLH-DSA.
And that raises a very interesting question.
If ML-DSA already provides post-quantum signatures, why do we need a completely different signature family based almost entirely on hash functions?
What makes hash-based cryptography attractive?
What are one-time signatures?
Why do Merkle trees appear?
How does SPHINCS+ avoid maintaining state?
Why are SLH-DSA signatures much larger than ML-DSA signatures?
And why might cryptographic diversity be valuable even when one algorithm is more efficient?
That will be the topic of the next article:
Why Do We Need Hash-Based Signatures?
Inside SLH-DSA, Merkle Trees, SPHINCS+, and the Case for Cryptographic Diversity
There, we will move away from lattice mathematics almost completely.
And that is exactly what makes the comparison interesting.
Two algorithms can solve the same security problem —
digital signatures —
while relying on completely different mathematical foundations.
Thanks for reading.
This series began with quantum computation itself.
That led us to noise, quantum error correction, fault tolerance, Shor’s algorithm, the vulnerability of classical public-key cryptography, post-quantum cryptography, Learning With Errors, ML-KEM, and now ML-DSA.
What I find especially interesting is how far the discussion has moved.
We started with quantum mechanics.
Now we are discussing probability distributions of lattice signatures, Fiat–Shamir transforms, side-channel behavior, protocol identity, and systems engineering.
That progression is exactly why I enjoy studying the intersection of quantum computing and security.
A change in the computational model eventually changes the architecture of real-world trust.
References & Further Reading
National Institute of Standards and Technology
FIPS 204 — Module-Lattice-Based Digital Signature Standard.
The primary specification for ML-DSA. NIST finalized FIPS 204 on August 13, 2024.
CRYSTALS-Dilithium Team
CRYSTALS-Dilithium: Algorithm Specifications and Supporting Documentation.
ML-DSA is derived from Version 3.1 of CRYSTALS-Dilithium.
Vadim Lyubashevsky
Fiat-Shamir With Aborts: Applications to Lattice and Factoring-Based Signatures.
Oded Regev
On Lattices, Learning With Errors, Random Linear Codes, and Cryptography.
Chris Peikert
A Decade of Lattice Cryptography.
National Institute of Standards and Technology
Post-Quantum Cryptography Project.
NIST continues to evaluate additional signature families alongside its finalized PQC standards.
