Engineering · 2026-06-16

ML-DSA-87 and SLH-DSA-256 for Long-Lived Identity Assertions

By J. W. Bouckaert

ML-DSA-87 is the highest-security parameter set of FIPS 204, the NIST lattice signature standard. It sits at NIST security category 5, produces 4,627-byte signatures, and is the algorithm CNSA 2.0 specifies for general digital signatures in National Security Systems. For signatures that live for hours, such as JWT issuance, TLS certificates and webhook authentication, any ML-DSA parameter set is a reasonable choice. Long-lived identity assertions need a closer comparison.

A notarial verifiable credential signed in 2026 may need to verify in 2056. An enterprise SSO root key signed today may anchor a federation trust chain for fifteen years. An eIDAS Qualified Electronic Signature on a land registry transfer must remain admissible for the lifetime of the property record—often longer than the signer's lifetime. For this class of long-lived assertion, choosing a post-quantum signature algorithm is a multi-decade decision, made without knowing which mathematical assumptions will survive forty years of cryptanalysis.

This article compares ML-DSA-87 with SLH-DSA-SHAKE-256, the FIPS 205 hash-based scheme at the same security category, across the five axes that determine fitness for decade-scale credentials: cryptographic conservatism, signature size, verification cost, stateless deployment characteristics, and the position of each algorithm under CNSA 2.0 and the evolving eIDAS cryptographic catalogue.

Terminology

A small terminology note matters before the comparison. "ML-DSA-87" is the highest-security parameter set of the Module-Lattice-Based Digital Signature Algorithm standardised in FIPS 204, finalised by NIST in August 2024. The "87" refers to the rank parameter (k, ℓ) = (8, 7) of the underlying lattice, and the scheme targets NIST security category 5—equivalent to AES-256 against classical and quantum adversaries.

"SLH-DSA-256" is industry shorthand for the highest-security parameter sets of the Stateless Hash-Based Digital Signature Algorithm in FIPS 205. The full names are SLH-DSA-SHA2-256s, SLH-DSA-SHA2-256f, SLH-DSA-SHAKE-256s, and SLH-DSA-SHAKE-256f—four variants over two hash functions and two trade-offs (the "s" for small signature, the "f" for fast signing). The "256" again denotes category 5. Throughout this article we use SLH-DSA-256s as the canonical comparator because the small variant is the one that matters for long-lived storage: signing happens once, verification happens forever, and the size penalty of the fast variant is unjustifiable for archival use.

Both algorithms are stateless. Both reached final FIPS publication in August 2024. Both are NIST-approved for general digital signature use. The differences are everywhere else.

The five axes that matter for long-lived credentials

The first three rows describe the cryptographic assumption. The next four are its operational consequences: statefulness and the key and signature sizes. The last two are the policy position under CNSA 2.0 and ETSI preservation profiles.

Cryptographic conservatism

ML-DSA's security rests on the conjectured hardness of Module Learning With Errors and the related Module Short Integer Solution problem. Both problems sit inside the lattice family, which is the most cryptanalytically active area of post-quantum research and has been since Regev's foundational LWE work in 2005. The lattice family is well-studied, but well-studied is not the same as long-studied. Module-LWE specifically was placed on a worst-case to average-case footing in Langlois and Stehlé's 2015 paper, and the parameter selection for ML-DSA was finalised in the early 2020s during NIST's standardisation. Roughly two decades of intensive cryptanalysis on the lattice family is a substantial body of work, and no polynomial-time attack—classical or quantum—is known. The mathematical community's confidence in lattice hardness is well-founded.

But confidence is bounded by the depth of the assumption stack. ML-DSA's reduction goes: signature security → Module-LWE/SIS hardness → general lattice hardness conjecture. Each step is reasonable; the chain is finite and intelligible. SLH-DSA's reduction is simpler: signature security → SHAKE-256 preimage and second-preimage and collision resistance. SHAKE-256 is the Keccak-based extendable-output function standardised in FIPS 202 in 2015, but the underlying Keccak design has been studied since 2008, and the broader class of cryptographic hash functions—preimage-resistant, collision-resistant compression primitives—has been studied since the 1970s. If SHAKE-256 preimage resistance fails, the cryptographic apocalypse extends to every Bitcoin block, every Ethereum contract, every Linux package signature, every container image digest, and every TLS certificate fingerprint that any party has ever issued.

This is the actual content of the "more conservative" claim. SLH-DSA is not conservative because hash-based cryptography is intrinsically safer than lattice cryptography. It is conservative because the failure mode is correlated with civilisational cryptographic failure. An attacker capable of breaking SHAKE-256 preimage resistance has bigger problems to occupy them than your notarial signature. An attacker capable of breaking Module-LWE has, by contrast, broken exactly your post-quantum signatures and nothing else.

For a one-hour bearer token, this distinction is irrelevant. For a forty-year notarial credential, it is the entire point.

Signature size and long-term storage

The most visible operational cost of SLH-DSA is signature size: 29,792 bytes for SLH-DSA-SHAKE-256s versus 4,627 bytes for ML-DSA-87, a 6.4× expansion. For high-throughput signature workloads (TLS, JWT, attestation), this expansion is prohibitive. For long-lived credentials, the calculus is different.

A notarial VC is signed once and stored for the lifetime of the underlying record. SLH-DSA-SHAKE-256s adds about 25 KB of signature per credential over ML-DSA-87, stored once, and per-byte storage prices have fallen by roughly 8% a year since the 1980s. For a credential whose purpose is legal proof over decades, the extra storage is a small part of what it costs to keep.

What matters more than absolute size is transport cost during verification. A wallet presenting a long-lived credential over a constrained network (a mobile data session, a satellite link, an NFC near-field exchange) pays the signature size every time the credential is shown. For credentials shown rarely—once or twice per legal lifecycle—this is irrelevant. For credentials shown thousands of times (an enterprise SSO root that anchors millions of session tokens), it matters. The architectural answer for the latter case is a layered model rather than a choice of ML-DSA over SLH-DSA: the root signs intermediate certificates whose own signatures are smaller and verified more frequently—the same delegated-trust pattern PKI has used for thirty years.

Signing and verification cost

ML-DSA-87 is faster than SLH-DSA-SHAKE-256s at both signing and verification, and the gap is far larger at signing. Absolute times depend on the implementation, the platform and the build, so measure the two on your own hardware before sizing a signer.

The signing gap is the structural reason SLH-DSA-256s is not a general-purpose signature primitive: its signing cost makes it a poor fit for a synchronous request path. For long-lived credentials this is acceptable because signing is rare (once per notarial act, once per root rotation, once per qualified seal application) and can be moved off the request path entirely.

Verification is where the two schemes are closer, and verification is the operation a long-lived credential repeats. A credential signed once at issuance and verified for decades pays the slow operation once.

Stateless versus stateful

A common source of confusion is the contrast between stateful and stateless hash-based signatures. LMS and XMSS, standardised in NIST SP 800-208, are stateful—the signer must remember which one-time-key indices have been used, and a single state-reuse event is mathematically catastrophic. SLH-DSA, by contrast, is stateless. It uses the same WOTS+ and FORS hash-based primitives internally but addresses them via a hypertree keyed by a message-dependent randomiser, so no state must be persisted between operations.

For long-lived credential signers, statelessness is non-negotiable. The threat model includes:

• HSM migration across decades. The HSM that signs a notarial credential today will be retired, replaced, and possibly cloned during the credential's verification lifetime. A stateful signer would require provable state continuity across every such migration, which is essentially impossible to guarantee over forty years.
• Disaster-recovery restore. Long-lived signing keys live in escrow, in geographic replicas, and in offline backups. A stateful signer that is restored from a backup that predates the most recent signature immediately enables silent forgery. This is the failure mode that motivates the entire "stateful only for firmware and append-only logs" restriction in SP 800-208.
• Multi-party signing for qualified seals. eIDAS Qualified Trust Service Providers may shard a signing operation across multiple HSMs for separation-of-duties. Stateful schemes are incompatible with this without careful sub-tree allocation; stateless schemes are oblivious.

ML-DSA-87 is also stateless, so this argument does not distinguish it from SLH-DSA-256. It does, however, exclude LMS and XMSS from the long-lived-credential conversation entirely. Those algorithms are correct for append-only audit logs; they are not correct for archival credentials.

CNSA 2.0 and the policy pull

The U.S. National Security Agency's CNSA 2.0 suite, published as a Cybersecurity Information Sheet in September 2022, sets the cryptographic baseline for National Security Systems. The suite, as updated through 2024, lists:

• ML-KEM-1024 for key establishment;
• ML-DSA-87 for general digital signatures;
• LMS and XMSS (SP 800-208 parameters) for firmware and software signing;
• AES-256 for symmetric encryption;
• SHA-384 and SHA-512 for hashing.

CNSA 2.0 does not list SLH-DSA. The NSA CNSA 2.0 FAQ states that SLH-DSA is not part of CNSA and is not approved for any use in National Security Systems. For NSS software and firmware signing, CNSA 2.0 approves LMS and XMSS under NIST SP 800-208. ML-DSA-87 is the algorithm CNSA 2.0 specifies for general digital signatures. SLH-DSA is the stateless hash-based scheme standardised in FIPS 205.

Long-lived credentials outside National Security Systems sit under a different set of rules. Preservation services regulated under eIDAS and ETSI EN 319 401 keep a signature verifiable for decades, so signing throughput is a smaller constraint than the lifetime of the security assumption. Dual-signing with two distinct cryptographic foundations is a long-standing recommendation for high-assurance preservation. SLH-DSA-256 produces a large signature whose security reduces to SHAKE-256 preimage and collision resistance. That profile fits an archival credential. A high-rate JWT signer needs a smaller, faster signature, and SLH-DSA-256 is not a CNSA 2.0 algorithm.

The workload decides the algorithm. CNSA 2.0 specifies ML-DSA-87 for general signatures in National Security Systems, and LMS or XMSS for NSS software and firmware signing. A preservation workload outside NSS can use SLH-DSA-256 where the hash-based reduction is the requirement, or dual-sign ML-DSA-87 and SLH-DSA-256s where either family must be able to fail without retiring the credential.

Decision framework for identity-assertion workloads

There is no useful answer to "ML-DSA-87 or SLH-DSA-256" in the abstract. The actual decision is a per-workload mapping driven by three properties: assertion lifetime, signature frequency, and verifier population.

The pattern: as assertion lifetime grows, the optimal algorithm shifts from speed-optimised lattice (ML-DSA-65) to conservative lattice (ML-DSA-87) to conservative hash-based (SLH-DSA-256s) and ultimately to dual-signed combinations that survive a break in either family. The same logic that drove hybrid classical+post-quantum signatures during the migration window applies recursively inside the post-quantum era: when uncertainty is unbounded, sign twice.

Dual-signing in practice

For credentials at the longest end of the lifetime spectrum, the production answer is to attach both signatures to the credential, indexed under distinct JOSE headers, and require that either signature validates at verification time. The credential remains verifiable so long as at least one family—Module-LWE or SHAKE-256 preimage resistance—remains intact.

The cost is signature overhead: about 4.6 KB for ML-DSA-87 plus about 29.8 KB for SLH-DSA-256s, roughly 34.4 KB of signature material per credential, plus headers. For any credential whose claims payload is smaller than that, the signatures are the larger part of the credential. For a credential signed once and stored for forty years, that overhead is what keeps it verifiable after a break in either family.

The verification logic is straightforward: the verifier attempts both signatures, accepts on either success, and emits structured telemetry on which family was used (so the operator can monitor for partial breaks). A verifier library can wrap this in one call with a deterministic precedence: SLH-DSA-256s checked first when both signatures are present, on the grounds that a future SHAKE-256 break is the rarer event and a verifier should spend the more conservative budget first. This describes the design: the PasskeyBridge SDK does not implement SLH-DSA.

The algorithms PasskeyBridge signs with today

The table above is a decision framework. What the platform itself does is narrower:

• ES256 plus a detached ML-DSA-65 signature on credentials and attestations, by default on every plan since August 8, 2026. That covers the short-lived tier: authentication and attestation receipts.
• ES384 plus ML-DSA-87 for tenants on the Enterprise ML-DSA-87 add-on, the medium-horizon tier.
• Not implemented: SLH-DSA, LMS and XMSS. Key agreement in BLAST is X25519, and a client can also send an ML-KEM-768 encapsulation key so the tunnel key mixes both secrets. Identity tokens are not encrypted with ML-KEM. Post-quantum signatures are the ML-DSA layer above.

For the archival tiers, the dual-signed ML-DSA-87 plus SLH-DSA-256s profile is the recommendation; the platform does not issue it today. Each workload should use the algorithm whose security model and operational profile fit the assertion's lifetime: ML-DSA-65 for one-hour tokens, and SLH-DSA-256s for forty-year notarial credentials, where the security assumption matters more than signature size.

The post-quantum migration is finished when each credential is signed with the algorithm whose threat horizon matches the credential's own, and deploying ML-DSA alone does not get there. For long-lived identity assertions, that horizon is measured in decades, and the algorithm is SLH-DSA-256—or, when the stakes justify it, both.

Read the PasskeyBridge security architecture →

Start free · Test the API