ML-DSA (FIPS 204) and SLH-DSA (FIPS 205)

ML-DSA (Module-Lattice-based Digital Signature Algorithm), standardized as FIPS 204, is derived from CRYSTALS-Dilithium. Dilithium was designed by Ducas, Kiltz, Lepoint, Lyubashevsky, Schwabe, Seiler, and Stehle and submitted to NIST in 2017. It uses the Fiat-Shamir with aborts framework applied to Module-LWE, producing a practical signature scheme with strong security proofs.

Classical Fiat-Shamir transforms interactive identification protocols into signatures. For lattice schemes, a direct application leaks information about the secret key through the response vector. The "with aborts" technique by Lyubashevsky adds rejection sampling: the signer checks if the response would reveal information and aborts and retries if so. This adds a small signing overhead but is essential for security.

To sign, ML-DSA samples a masking vector y from a uniform distribution, computes a commitment w = Ay, hashes (message, w) to get a challenge polynomial c, and computes response z = y + cs. Rejection sampling checks if z reveals information about s. If the check passes, the signature is (c, z) along with a hint for efficient verification. If not, the process repeats.

ML-DSA defines three parameter sets: ML-DSA-44 (NIST security level 2, ~128-bit), ML-DSA-65 (level 3, ~192-bit), and ML-DSA-87 (level 5, ~256-bit). The numbers refer to module ranks in the scheme. Public key sizes are 1312, 1952, and 2592 bytes respectively. ML-DSA-65 signature size is 3293 bytes, compared to 64 bytes for Ed25519 at 128-bit security.

The most significant disadvantage of ML-DSA compared to ECDSA or EdDSA is signature size. ML-DSA-65 signatures are 3293 bytes versus 64 bytes for Ed25519. For protocols that transmit many signatures (TLS certificate chains, code signing), this increases bandwidth. However, ML-DSA signing and verification are very fast (comparable to or faster than ECDSA), so the trade-off is primarily in communication cost.

SLH-DSA (Stateless Hash-Based Digital Signature Algorithm), standardized as FIPS 205, is derived from SPHINCS+. Unlike lattice schemes, SLH-DSA's security relies only on the collision resistance and second-preimage resistance of the underlying hash function (SHA-256 or SHAKE-256). This makes SLH-DSA extremely conservative: it remains secure even if lattice assumptions are broken.

SLH-DSA builds on WOTS+ (Winternitz One-Time Signature), a hash-based scheme where the private key is a set of random strings and the public key is obtained by repeatedly hashing each. Signing involves partially hashing based on the message bits. WOTS+ can only be used once per key pair safely; using it twice leaks information. SLH-DSA builds many-time signing on top of WOTS+ via trees.

SLH-DSA uses a hypertree: a tree of Merkle trees. Each leaf is the public key of a WOTS+ instance. The root is the SLH-DSA public key. A signature consists of the WOTS+ signature for the message and the authentication path from the leaf to the root. The hypertree structure allows many signatures from a single key pair by using different WOTS+ leaves.

SLH-DSA has 12 parameter sets combining hash function (SHA-256 or SHAKE-256), security level (128s/128f, 192s/192f, 256s/256f), and optimization (s = small signatures, f = fast signing). The 128f variant has 7856-byte signatures with fast signing; 128s has 7856 bytes but slower. All are much larger than ML-DSA but have the strongest possible security assumption.

ML-DSA is preferred when performance and bandwidth matter and lattice assumptions are trusted. SLH-DSA is preferred for extremely conservative deployments where only hash function security is trusted, or for future-proofing against potential lattice breaks. Certificate authorities and government systems that sign rarely but need maximum assurance might favor SLH-DSA, while TLS servers signing frequently would prefer ML-DSA.

FN-DSA (FIPS 206, based on FALCON) offers smaller signatures than ML-DSA (897 bytes for FALCON-512 at 128-bit security) using NTRU lattices and Gaussian sampling. However, FALCON requires careful constant-time implementation to avoid side-channel attacks from the Gaussian sampler. FIPS 206 is expected to be standardized after FIPS 203-205 and will provide a high-performance option for resource-constrained environments.

ML-DSA (FIPS 204) uses Fiat-Shamir with aborts over Module-LWE, offering fast signing with 3-KB signatures (at 192-bit security). SLH-DSA (FIPS 205) uses hash-based Merkle trees (WOTS+), relying only on hash function security with 7-50 KB signatures. ML-DSA is preferred for performance-sensitive applications; SLH-DSA for maximum conservatism. FN-DSA (FALCON, FIPS 206) will add a smaller-signature lattice option.