What is SLH-DSA?
SLH-DSA is a hash-based post-quantum signature option. It signs and verifies data, but it uses a different design approach from ML-DSA.
Hash-Based Signature Option
SLH-DSA is best pictured as a post-quantum signature option that uses hash-based constructions rather than the lattice-based approach used by ML-DSA.
Lattice-based signature
A post-quantum digital signature algorithm defined in NIST FIPS 204.
Stateless hash-based signature
A post-quantum digital signature algorithm defined in NIST FIPS 205, with different size, performance, and implementation trade-offs.
ML-DSA and SLH-DSA are both post-quantum signature algorithms. ML-DSA is lattice-based. SLH-DSA is hash-based.
Short Answer
SLH-DSA is the NIST-standardised stateless hash-based post-quantum digital signature algorithm.
The signature role
It creates and verifies signatures so authenticity and integrity can be checked.
The design difference
SLH-DSA is hash-based, while ML-DSA uses a lattice-based approach.
The practical comparison
The point is not to decide that one is always better. The point is to compare fit, support, size, performance, and operational impact by use case.
Core Explanation
SLH-DSA is a post-quantum digital signature algorithm
SLH-DSA is designed for digital signatures.
The role is authenticity and integrity. It is not confidentiality. It is not key exchange. It is not full-message encryption.
- Key generation creates a public verification key and private signing key
- Signing uses the private signing key
- Verification uses the public verification key
- The result is a valid or invalid signature check
SLH-DSA is not ML-KEM
This distinction matters.
A system may need both key establishment and signatures. For example, a secure protocol may need one mechanism to establish shared keys and another mechanism to authenticate identity.
That does not mean one algorithm does both jobs. SLH-DSA signs. It does not create shared session secrets.
SLH-DSA comes from the NIST PQC standardisation process
SLH-DSA is defined in NIST FIPS 205.
SLH-DSA is not only a research name or vendor label. It is a standardised post-quantum signature algorithm.
A standard defines the algorithm. Deployment still depends on protocol support, certificate ecosystem support, library support, product support, signing workflows, verification workflows, vendor roadmap, performance and size constraints, testing, and operational ownership.
Some readers may also see the name SPHINCS+ in older documents, research material, or vendor discussions. For this learning hub, use SLH-DSA as the standard name.
SLH-DSA is hash-based
The important distinguishing feature is that SLH-DSA is hash-based.
At a high level, it relies on cryptographic hash-function constructions rather than lattice-based assumptions.
This matters because hash-based signatures have a different design history and different implementation trade-offs from lattice-based signatures.
SLH-DSA does not use the same lattice-based approach as ML-DSA. It builds signatures from hash-based constructions.
Hash Foundation, Without a Hash-Tree Tutorial
This MVP does not include a separate hash function page, so the needed context is included directly inside the SLH-DSA page.
Hash function
A one-way function that turns input data into a fixed-size output.
One-way property
It should be hard to reconstruct the original input from the hash output.
Collision resistance
It should be hard to find two different inputs with the same hash output.
Hash-based signatures
Signature constructions that use hash functions as core building blocks.
This is not the full algorithm. It is the mental model.
What Stateless Means
Hash-based signatures can be stateful or stateless.
Stateful schemes require careful tracking of signing state. If signing state is reused incorrectly, security can fail.
SLH-DSA is stateless. For this page, the simple meaning is that SLH-DSA avoids requiring the signer to maintain a fragile per-signature state counter.
That does not mean implementation is trivial. Teams still need correct implementation, secure key management, tested libraries, and careful integration.
What Actually Moves or Gets Stored?
Private signing key
Signer keeps it secret and uses it to create signatures.
Public verification key
Can be shared and used to verify signatures.
Data
The content being signed, sent, stored, published, installed, or processed.
Signature
Travels or is stored with the data and allows verification.
SLH-DSA does not encrypt the data. It helps verify authenticity and integrity.
Parameter Sets Without Going Too Deep
SLH-DSA has multiple approved parameter sets. The practical point is not to memorise all names.
SHA2 or SHAKE
The hash-function family used inside the construction.
128, 192, or 256
Security-strength category.
s variant
Designed for relatively smaller signatures.
f variant
Designed for relatively faster signature generation.
Parameter choices affect security strength, signature size, signing speed, verification behaviour, and implementation fit.
Why SLH-DSA Is Compared with ML-DSA
ML-DSA and SLH-DSA are both post-quantum signature algorithms, but they are not the same design.
ML-DSA
Lattice-based digital signature algorithm defined in FIPS 204.
SLH-DSA
Hash-based digital signature algorithm defined in FIPS 205.
Do not treat this as a winner/loser table. The better question is which signature option fits this system, protocol, ecosystem, and operational requirement.
Why It Matters
SLH-DSA matters because post-quantum migration is not only about ML-KEM and key establishment.
Signatures also need attention
Some systems rely on signatures for trust, authenticity, and tamper detection.
It adds a second signature option
SLH-DSA gives teams another standardised post-quantum signature approach to understand alongside ML-DSA.
The better question is: where do signatures matter in our systems, which signature options are supported, and what are the operational trade-offs?
Practical Example
A vendor roadmap mentions ML-DSA and SLH-DSA
A vendor roadmap mentions support for ML-DSA and SLH-DSA. A weak response would be to ask only which one is stronger.
A better response is to ask which product or service is in scope, whether this is for certificates, code signing, firmware, documents, or another signature use case, which algorithm is supported today, which one is planned, what the signature sizes and performance implications are, which clients or devices must verify the signatures, and how this will be tested and recorded in the cryptographic inventory.
This keeps the discussion practical.
Operational Watch-Outs
Teams should avoid treating SLH-DSA as a simple checkbox.
Signature size
Hash-based signatures can have different size implications from other signature schemes.
Signing speed
Some parameter choices prioritise faster signing, while others prioritise smaller signatures.
Verification environment
Verifiers must support the selected signature approach.
Signing workflow
Signing systems may need tooling and process changes.
Vendor roadmap
Products and platforms may support algorithms at different times.
Long-term trust
Some signed artefacts must remain verifiable for years.
The point is not to make SLH-DSA sound difficult. The point is to show that signature choices affect real systems.
What It Does Not Do
SLH-DSA has a specific role: digital signatures.
What Techies Should Notice
Technical teams do not need to implement SLH-DSA from scratch, but they should understand what changes operationally.
The better question is: how is SLH-DSA integrated, tested, configured, monitored, and supported in the signing and verification workflows we actually use?
Common Misunderstanding
SLH-DSA is simply better or worse than ML-DSA.
SLH-DSA and ML-DSA are different post-quantum signature approaches. The practical choice depends on standards guidance, ecosystem support, implementation fit, performance, size, and the specific system.
What to Remember
One-Sentence Summary
SLH-DSA is the NIST-standardised stateless hash-based post-quantum digital signature algorithm.
Three Key Points
- SLH-DSA is for signatures, not key establishment.
- It is hash-based, while ML-DSA is lattice-based.
- It is stateless, so it does not require fragile per-signature state tracking.
- It is defined in NIST FIPS 205.
- It should be compared with ML-DSA by use case, ecosystem support, size, performance, and operational trade-offs.