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. SLH-DSA is a stateless hash-based signature scheme, meaning its security depends entirely on the collision resistance of an underlying hash function rather than on any algebraic or lattice-based mathematical assumption. This distinguishes SLH-DSA fundamentally from ML-DSA and ML-KEM, both of which are based on Module-LWE lattice problems.
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.
“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 among the oldest and most conservatively analyzed approaches to post-quantum digital signatures. Their security reduces to a single assumption: that the underlying hash function is collision resistant. SHA-2 and SHA-3 families, which have been extensively analyzed for decades, are the hash function options in FIPS 205. No quantum algorithm is known to break collision resistance of strong hash functions faster than Grover's algorithm provides a quadratic speedup for generic search and Grover's speedup against hash collision resistance does not provide a practically exploitable attack at SHA-256 or SHA-3 security levels.
The mathematical connection between hash-based signature security and hash function collision resistance is tight and well-understood. Security proofs for schemes in the SPHINCS+/SLH-DSA family do not rely on unproven assumptions about hard problems other than hash function collision resistance. This makes SLH-DSA one of the best-understood post-quantum signature schemes from a security foundations perspective, providing high confidence that the security analysis will hold even as the broader field of quantum-resistant cryptography matures.
Why Algorithm Diversity Matters
Algorithm diversity in post-quantum cryptography means deploying algorithms based on different mathematical assumptions so that a breakthrough affecting one assumption does not compromise the entire cryptographic infrastructure. ML-KEM and ML-DSA are both based on Module-LWE lattice problems; SLH-DSA is based solely on hash function collision resistance. If a future advance in lattice cryptanalysis or quantum computing weakens Module-LWE, lattice-based algorithms would be affected while SLH-DSA would remain secure.
NIST's decision to standardize both lattice-based algorithms and SLH-DSA reflects this diversity principle. For the most critical, long-lived trust anchors in an organization root certificate authority keys that may be trusted for decades, firmware signing roots embedded in hardware that cannot be easily updated the combination of ML-DSA for performance-sensitive signing and SLH-DSA for conservative trust anchors provides stronger overall security than either algorithm alone. CNSA 2.0 specifically recommends SLH-DSA for software and firmware signing in National Security System contexts.
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 is slower to sign and produce larger signatures than ML-DSA. Signing with SLH-DSA-SHA2-256s takes significantly longer than signing with ML-DSA-65 due to the hypertree computation required. Signature sizes are also substantially larger: an SLH-DSA-SHA2-256s signature is approximately 29,792 bytes compared to approximately 3,293 bytes for ML-DSA-65. Public keys, however, are very small 64 bytes for SLH-DSA-SHA2-256s and verification is relatively fast.
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 the preferred algorithm for post-quantum root CA keys because its security independence from lattice assumptions reduces the risk of a single algorithmic breakthrough invalidating the trust anchor. Root CAs sign relatively rarely typically only when issuing intermediate CA certificates so SLH-DSA's slower signing performance is not a practical constraint. ETSI TS 119 312, which specifies cryptographic suites for European electronic signature infrastructure, is being updated to incorporate post-quantum signature algorithms with considerations for trust anchor longevity.
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 device designs, embedding an SLH-DSA verification key in hardware from the outset protects against future algorithm compromise for the device's entire operational lifetime. CNSA 2.0 explicitly requires National Security Systems to use SLH-DSA for software and firmware signing, reflecting NSA's assessment that the long-term trust requirements of firmware verification align with SLH-DSA's security properties. Commercial device manufacturers should consider SLH-DSA for firmware signing roots in products with operational lifetimes beyond five years.
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.
ETSI TS 119 312 and the associated European standards for advanced electronic signatures address long-term signature validity through timestamping and re-signing mechanisms that can extend signature validity as algorithms are updated. For new archival signing operations, using SLH-DSA from the outset provides the strongest available foundation for long-term signature integrity, combining quantum resistance with security based only on hash function collision resistance rather than potentially evolving lattice assumptions.
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
SLH-DSA support has been added to major cryptographic libraries following FIPS 205 finalization. The Open Quantum Safe (liboqs) library provides cross-platform SLH-DSA implementations for all FIPS 205 parameter sets. OpenSSL 3.x includes SLH-DSA support through its post-quantum provider. Language-level libraries in Rust, Python, and Go have OQS bindings or native post-quantum extensions that include SLH-DSA. HSM vendors are progressively adding SLH-DSA key generation and signing support.
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]
- [4]NSANSA CNSA 2.0(2022)Commercial National Security Algorithm Suite 2.0
- [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.