SLH-DSA — the hash-based backup

After ML-KEM and ML-DSA, a reasonable question is: why does NIST need a third standard? ML-DSA already handles digital signatures. The answer is about security diversity and risk management, two principles that run through the entire PQC migration strategy.

ML-KEM and ML-DSA both rely on the Module Learning With Errors (M-LWE) problem, a lattice-based mathematical structure. This is a well-studied problem and the community's confidence in its quantum resistance is high. But it is still a relatively young cryptographic foundation compared to hash functions. Hash functions have been the bedrock of cryptography for decades. SHA-2, SHA-3, and their predecessors have been analyzed exhaustively by thousands of researchers. Their security properties are as well-understood as anything in cryptography.

SLH-DSA's security depends entirely on the properties of hash functions, with no additional number-theoretic assumptions. If a breakthrough attack were ever discovered against lattice-based cryptography, a scenario considered unlikely but not impossible, SLH-DSA would remain secure. It is the cryptographic equivalent of a second deadbolt on a door that already has a high-tech lock.

The choice between SLH-DSA and ML-DSA is not about which is more secure in an absolute sense, both are believed to be quantum-resistant. It is about which security foundation you prefer and what performance trade-offs are acceptable for your use case.

The large signature sizes are the main practical constraint of SLH-DSA. The smallest parameter set (SLH-DSA-SHA2-128s) produces 7,856-byte signatures. The largest (SLH-DSA-SHAKE-256f) produces 49,856 bytes. For comparison, the entire content of the US Constitution is around 45,000 bytes. A root CA certificate signed with SLH-DSA-256f would have a signature nearly as large as the document itself. This is why SLH-DSA is selected deliberately for specific high-value use cases rather than deployed everywhere.

The decision between SLH-DSA and ML-DSA comes down to the answer to one question: Is the security assurance of hash-based cryptography worth the performance trade-off for this specific use case?

The key insight about "stateless" in SLH-DSA's name: earlier hash-based signature schemes (XMSS, LMS) required careful state management, using the same key twice in certain stateful schemes could catastrophically weaken security. SLH-DSA is stateless, meaning each signing operation is independent and there is no state to track. This makes it significantly easier to deploy safely, especially in distributed or redundant signing environments.

With Lesson 1.4 complete, all three NIST standards are in place. The picture of what replaces what is now complete: ML-KEM replaces RSA and ECDH for key exchange. ML-DSA is the general-purpose post-quantum signature. SLH-DSA is the conservative, high-assurance signature for the most critical and long-lived use cases.

In most organizations' migration work, SLH-DSA will appear in exactly one context initially: the question of what algorithm to use for new root CA keys. That decision is consequential, root CA keys last for decades, and it is where the SLH-DSA trade-off is most directly relevant. For everything else in a typical enterprise environment, ML-DSA is the working choice.