What Is SLH-DSA?
SLH-DSA (Stateless Hash-Based Digital Signature Algorithm) is the post-quantum digital signature standard published by NIST as FIPS 205 in August 2024. It is derived from the SPHINCS+ algorithm submitted to the NIST PQC Standardization Project. Its security relies on properties of its underlying hash functions and pseudorandom constructions, rather than lattice-based mathematical assumptions. This distinguishes SLH-DSA from ML-KEM and ML-DSA.
NIST standardized SLH-DSA alongside ML-DSA to provide algorithm diversity in post-quantum signature infrastructure. If a cryptanalytic breakthrough weakened the Module-LWE problem underpinning lattice-based algorithms, SLH-DSA's security would be unaffected. Organizations deploying SLH-DSA for their most critical trust anchors gain insurance against any single mathematical breakthrough affecting all post-quantum signatures simultaneously.
Source summary (not a direct quotation)
This standard specifies a stateless hash-based digital signature scheme, SLH-DSA, which is derived from the SPHINCS+ submission to the NIST Post-Quantum Cryptography Standardization Project.
The Security Foundation: Hash-Based Cryptography
Hash-based signatures are a conservatively analyzed approach to post-quantum digital signatures. FIPS 205 provides SHA-2 and SHAKE parameter sets. Their security relies on several hash-function properties, including resistance to relevant preimage and collision attacks, together with the security of the scheme's pseudorandom constructions. Grover's algorithm gives a quadratic speedup for generic search; collision-finding attacks require a separate analysis and should not be described as the same problem.
SLH-DSA parameter sets are designed to meet NIST security categories 1, 3, and 5 under the standard's security analysis. Hash-based constructions provide a different security foundation from lattice-based signatures, but do not remove the need for correct implementations, secure key management, or continuing cryptanalytic review.
Why Algorithm Diversity Matters
Algorithm diversity means using constructions with different security foundations to reduce dependence on a single mathematical assumption. ML-KEM and ML-DSA use lattice-based constructions, while SLH-DSA uses hash-based constructions. A breakthrough against lattice problems would not automatically apply to SLH-DSA, although each algorithm still depends on its own assumptions and implementation.
NIST's decision to standardize lattice-based algorithms alongside SLH-DSA reflects this diversity principle. Commercial organizations can evaluate SLH-DSA for long-lived trust anchors where protocol support, signature size, and signing speed permit. SLH-DSA is not approved for NSS use. CNSA 2.0 software and firmware signing options include validated ML-DSA-87, LMS, and XMSS under the applicable NSA guidance.
FIPS 205 Parameter Sets
NIST FIPS 205 defines multiple parameter sets organized along two dimensions: hash function choice (SHA-2 or SHAKE) and security level (NIST levels 1, 3, and 5). This produces a family of 12 parameter sets: SLH-DSA-SHA2-128s, SLH-DSA-SHA2-128f, SLH-DSA-SHA2-192s, SLH-DSA-SHA2-192f, SLH-DSA-SHA2-256s, SLH-DSA-SHA2-256f, and corresponding SHAKE variants. The 's' (small) variants optimize for signature size at the cost of signing speed; the 'f' (fast) variants optimize for signing speed at the cost of signature size.
For most production use cases, SLH-DSA-SHA2-256s provides NIST level 5 security with the smallest signature sizes in the level 5 family. SLH-DSA-SHA2-128f at level 1 provides faster signing when throughput is important and level 1 security is sufficient. The SHA-2 variants are typically preferred in environments with existing SHA-2 hardware acceleration. SHAKE variants are suitable for environments with SHAKE hardware support or requirements for SHA-3 family hash functions.
How SLH-DSA Works: XMSS Trees and FORS
SLH-DSA builds on two components: a few-time signature scheme called FORS (Forest of Random Subsets) and a hypertree structure of Winternitz One-Time Signature Plus (WOTS+) chains organized into XMSS (eXtended Merkle Signature Scheme) trees. The hypertree provides a hierarchical structure that allows many signatures to be produced from a single root public key by traversing different branches. The FORS component provides the message-signing capability at the leaf level.
The stateless property of SLH-DSA distinguishing it from earlier XMSS and LMS schemes means signing does not require maintaining state between signatures. Stateful hash-based schemes like XMSS require the signer to track which one-time keys have been used; reusing a one-time key breaks security. SLH-DSA avoids this by using a randomized signing process that derives a unique one-time key for each message from a deterministic pseudorandom function seeded with the signing private key and message-dependent randomness, eliminating state management requirements.
Performance Characteristics and Trade-offs
SLH-DSA generally signs more slowly and produces larger signatures than ML-DSA. An SLH-DSA-SHA2-256s signature is 29,792 bytes, compared to 3,309 bytes for ML-DSA-65; these parameter sets target different security categories. The SLH-DSA-SHA2-256s public key is 64 bytes. Measure signing and verification performance on the intended hardware and implementation rather than assuming a universal speed advantage.
These performance characteristics make SLH-DSA a poor fit for high-volume signing workloads such as TLS certificate verification at scale or high-throughput code signing pipelines. They make it well-suited for infrequent, high-importance signing operations where signature size and signing time matter less than long-term security assurance: root CA certificate issuance, firmware signing for devices with decades-long deployment lifetimes, archival document signing, and trust anchor operations generally.
When to Use SLH-DSA vs. ML-DSA
The choice between SLH-DSA and ML-DSA depends on the signing context's requirements for throughput, signature size, and security assurance level. ML-DSA-65 is the recommended default for most production signing workloads: code signing pipelines, intermediate CA certificate issuance, API authentication tokens, and general-purpose digital signatures where signing speed and signature size are operationally relevant. ML-DSA's lattice-based construction is well-analyzed and provides strong security at acceptable size and performance.
SLH-DSA is recommended for root certificate authorities, firmware signing roots embedded in hardware, long-term archival signatures (where the signature must remain verifiable and unforgeable for decades), and any trust anchor where algorithm independence from lattice assumptions is valued. Where both ML-DSA and SLH-DSA are feasible for example, offline root CA certificate issuance, which is a rare and slow operation regardless of algorithm SLH-DSA provides additional security assurance with no practical throughput penalty.
Root Certificate Authorities and Trust Anchors
Root CA certificates are among the most sensitive and longest-lived cryptographic assets in any organization's PKI. They are self-signed, typically valid for 20-30 years, embedded in operating system and browser trust stores, and serve as the ultimate trust anchor for all certificate chain verification. If a root CA private key is compromised whether through cryptanalysis, key theft, or algorithm weakness all certificates signed under that root must be revoked and re-issued, a massively disruptive operation affecting every system that trusts that root.
SLH-DSA is an option for post-quantum root CA keys where the trust ecosystem and applicable policies support it. Its independence from lattice assumptions can provide algorithm diversity, but signature sizes, verification costs, certificate formats, and relying-party support must be evaluated. Root CAs sign relatively rarely, so slower signing may be acceptable. Consult the current ETSI TS 119 312 and relevant certificate profiles for European electronic signature deployments.
Firmware Signing Use Cases
Firmware signing for embedded systems IoT devices, automotive controllers, industrial control equipment, satellite systems uses digital signatures to verify that firmware updates are authentic and have not been tampered with. The verification key is typically embedded in hardware at manufacture time and cannot be updated in the field. If the firmware signing algorithm is broken in the future, all devices trusting that signing key become vulnerable to malicious firmware injection.
For new commercial device designs, SLH-DSA can be evaluated for firmware signing where verification cost, signature size, and update mechanisms support it. No algorithm guarantees protection for a device's entire lifetime, so recovery and algorithm-update plans remain important. For National Security Systems, CNSA 2.0 does not approve SLH-DSA; consult NSA guidance for validated ML-DSA-87, LMS, and XMSS implementations.
Long-Term Archival Signatures
Legal documents, financial records, and regulatory filings often require digital signatures that must remain verifiable and unforgeable for many years or decades. If the signature algorithm used at signing time is broken in the future, archived documents could potentially be forged retroactively, undermining the evidentiary value of the archive. Long-term archival signature schemes must account for the possibility that signing algorithms will need to be superseded over the signature's lifetime.
European electronic-signature standards address long-term validation through preservation mechanisms such as timestamping and renewal as algorithms evolve. SLH-DSA offers a hash-based alternative to lattice-based signatures where supported by the relevant profiles. Long-term integrity still requires secure key handling, retained validation evidence, and a plan to renew protection when assumptions or standards change.
Hybrid Signatures Combining SLH-DSA and ML-DSA
In environments that require both the throughput of ML-DSA and the algorithm independence of SLH-DSA, hybrid signature schemes can combine both. A hybrid signature contains both an ML-DSA signature and an SLH-DSA signature over the same message; verification requires both signatures to be valid. An adversary who breaks either algorithm cannot forge a signature that passes hybrid verification, providing the security of whichever algorithm is stronger at any given time.
Hybrid post-quantum signatures are most appropriate for the highest-security signing contexts where operational overhead is acceptable: root CA certificate issuance, long-term compliance records, and treaty-level diplomatic documents. For most enterprise applications, ML-DSA alone provides sufficient post-quantum security with manageable size and performance characteristics, and the additional overhead of SLH-DSA hybrid signing is not necessary.
Library and Integration Support
OpenSSL 3.5 added native SLH-DSA support, and liboqs provides implementations for evaluation. Bindings and HSM support vary by product and version. Confirm the exact FIPS 205 parameter sets, certificate-format support, and implementation validation requirements before integration; library support alone is not proof of FIPS 140 module validation.
When integrating SLH-DSA into signing infrastructure, verify that the implementation uses the FIPS 205 parameter set identifiers and not pre-standardization SPHINCS+ parameters, which differ from the final standard. Libraries updated to FIPS 205 compliance after August 2024 should use the correct parameters; older implementations built against pre-standard SPHINCS+ are not interoperable with FIPS 205 compliant implementations. Confirm the parameter set names match the FIPS 205 specification before production deployment.
References
- [1]NISTNIST FIPS 205(2024)Stateless Hash-Based Digital Signature Standard (SLH-DSA)
- [2]NISTNIST FIPS 204(2024)Module-Lattice-Based Digital Signature Standard (ML-DSA)
- [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]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.