NIST finalized two post-quantum signature standards on the same day in August 2024, and that decision still confuses engineers picking a signature scheme in 2026. ML-DSA (FIPS 204, built on CRYSTALS-Dilithium) and SLH-DSA (FIPS 205, built on SPHINCS+) both survive a quantum computer attack that would break RSA and ECDSA. They do it in almost opposite ways. ML-DSA leans on lattice math and ships signatures under 5 KB. SLH-DSA leans on plain hash functions and ships signatures that run past 49 KB in some configurations. One signs in a tenth of a millisecond. The other can take over a second. Picking wrong doesn’t break security since both meet the same FIPS bar, but it can quietly break a budget, a battery life target, or a TLS handshake’s latency margin. This piece breaks down the exact byte counts, the benchmark numbers from three independent sources, what OpenSSL, Cloudflare, AWS, and Google Cloud have actually shipped, and which algorithm fits which job.

What Is ML-DSA? The Lattice-Based Default

ML-DSA stands for Module-Lattice-Based Digital Signature Algorithm. NIST standardized it as FIPS 204 on August 13, 2024, and it descends directly from CRYSTALS-Dilithium, the submission that won NIST’s original post-quantum signature competition. The algorithm builds its security on the Module Learning With Errors problem, a lattice-based hardness assumption that has held up against both classical and quantum cryptanalysis since it entered serious academic review over a decade ago.

ML-DSA runs the Fiat-Shamir with aborts construction over a polynomial ring, which is a fancy way of saying it rejects and retries candidate signatures internally until one meets a size bound, then outputs it. That retry loop is why signing takes a variable but still sub-millisecond amount of time on modern CPUs. NIST ships three parameter sets: ML-DSA-44, ML-DSA-65, and ML-DSA-87, numbered by security category (roughly matching AES-128, AES-192, and AES-256 strength). ML-DSA-65 is the one most vendors default to for general TLS and code-signing use, while ML-DSA-87 is the one the NSA names explicitly in its CNSA 2.0 firmware-signing guidance.

NIST’s own PQC project slides describe ML-DSA as having “good performance, simple implementation, moderate public-key and signature size,” and the agency states plainly that it expects ML-DSA to become the main NIST-approved signature scheme for general-purpose use. That framing matters for this whole comparison: ML-DSA was never designed to be the exotic backup option. It was built to replace RSA and ECDSA at scale.

What Is SLH-DSA? The Hash-Based Backup Standard

SLH-DSA stands for Stateless Hash-Based Digital Signature Algorithm. NIST standardized it as FIPS 205 on the same day as ML-DSA, and it’s built directly from SPHINCS+, a design that traces back to a 2017 NIST competition submission. Where ML-DSA bets on a lattice problem, SLH-DSA bets on nothing more exotic than the collision resistance of a hash function, either SHA-2 or SHAKE depending on the parameter set. That’s the entire point of the algorithm: no new mathematical assumption to trust, just the same hash primitives that have already survived decades of public cryptanalysis.

FIPS 205 defines 12 separate parameter sets, split across three security categories (1, 3, and 5) and two speed profiles each, marked “s” for small and “f” for fast. The “s” variants shrink the signature at the cost of slower signing. The “f” variants speed up signing by producing a bigger signature. Every SLH-DSA key pair is tiny regardless of parameter set: the public key is exactly 2n bytes and the private key is exactly 4n bytes, where n is 16, 24, or 32 depending on the security category. The signature is where all the size lives, and it lives there because SLH-DSA builds its proof from a many-layered hash tree structure rather than a single lattice equation.

NIST treats SLH-DSA explicitly as insurance. If a future breakthrough in lattice cryptanalysis ever weakens Module-LWE, organizations that also deployed SLH-DSA somewhere in their signing chain keep a fallback that doesn’t share that risk. The tradeoff is that the insurance costs real bytes and real milliseconds, which is exactly what the numbers below spell out.

SLH-DSA vs ML-DSA: Full Specs Comparison Table

Here’s every core spec side by side, pulled from the FIPS 204 and FIPS 205 text and cross-checked against the OpenSSL and wolfSSL implementation docs.

PropertyML-DSA (FIPS 204)SLH-DSA (FIPS 205)
StandardFIPS 204, published Aug. 13, 2024FIPS 205, published Aug. 13, 2024
Underlying designCRYSTALS-DilithiumSPHINCS+
Security basisModule Learning With Errors (lattice)Hash function collision resistance
ConstructionFiat-Shamir with abortsStateless hash-based Merkle tree signatures
Parameter sets3 (ML-DSA-44, -65, -87)12 (SHA2/SHAKE, 128/192/256, s/f)
Public key, smallest set1,312 bytes (ML-DSA-44)32 bytes (SLH-DSA-SHA2-128s)
Private key, smallest set2,560 bytes (ML-DSA-44)64 bytes (SLH-DSA-SHA2-128s)
Signature, smallest set2,420 bytes (ML-DSA-44)7,856 bytes (SLH-DSA-SHA2-128s)
Signature, top security level4,627 bytes (ML-DSA-87)49,856 bytes (SLH-DSA-SHA2-256f)
Sign latency (p50, liboqs)0.116 ms (ML-DSA-44)11.06 ms (SLH-DSA-SHA2-128f)
Verify throughput (liboqs)29,200 verifications/sec1,500 verifications/sec
StatefulnessStatelessStateless
NSA CNSA 2.0 rolePrimary, ML-DSA-87 named for firmwareConservative alternate, no statefulness burden

Source figures come from the FIPS 204 and FIPS 205 specification tables, Utimaco’s published breakdown of the SLH-DSA parameter sets, and the QNSP PQC benchmark suite running on the liboqs reference implementation. Every number in this table is a directly published spec value or a directly published benchmark result, not an estimate.

Signature and Key Size: Where the Gap Really Shows

The size gap between these two algorithms is the single biggest reason engineers pick one over the other. ML-DSA-44’s 2,420-byte signature already beats RSA-4096 for equivalent post-quantum assurance. Stack it against SLH-DSA-SHA2-128s at 7,856 bytes and ML-DSA comes out 3.2 times smaller for a comparable security category. Push to the “fast” SLH-DSA variants, which trade size for speed, and the gap widens further: SLH-DSA-SHA2-128f hits 17,088 bytes, over 7 times larger than ML-DSA-44’s signature.

Keys flip the comparison entirely. ML-DSA-44 needs a 1,312-byte public key and a 2,560-byte private key. SLH-DSA-SHA2-128s needs just 32 bytes and 64 bytes respectively, both defined as fixed multiples of the security parameter n (public key is always 2n bytes, private key always 4n bytes, per the FIPS 205 text). That means SLH-DSA key material is roughly 40 times smaller than ML-DSA key material, even while its signatures run several times larger.

This split explains a lot of the deployment decisions later in this article. A protocol that exchanges keys once and signatures constantly (like a TLS handshake) wants small signatures, so it reaches for ML-DSA. A protocol that stores a signing key for years and only produces a handful of signatures off it (like a firmware root of trust) can tolerate a bulky signature in exchange for tiny, cheap-to-protect key material, so it can lean toward SLH-DSA without much practical cost.

Signing and Verification Speed: Benchmarks From Three Sources

Size differences are fixed by the spec. Speed differences depend on implementation and hardware, so it’s worth checking more than one benchmark before drawing conclusions. Here are three independent measurements, all run against liboqs-based implementations.

AlgorithmKeygenSignVerifySource
ML-DSA-440.034 ms0.116 ms0.035 msQNSP / liboqs benchmark
ML-DSA-650.061 ms0.189 ms0.053 msQNSP / liboqs benchmark
ML-DSA-870.093 ms~0.24 ms~0.09 msQNSP / liboqs benchmark
SLH-DSA-SHA2-128f0.485 ms11.06 ms0.680 msQNSP / liboqs benchmark
ML-DSA-440.299 ms0.734 ms0.166 msITB firmware-signing study
SLH-DSA-SHA2-128s206.07 ms1,430.19 ms1.16 msITB firmware-signing study

The QNSP suite (linked above) and a separate academic benchmark on post-quantum firmware signing both point the same direction, even though they measured different parameter sets on different hardware. In the QNSP numbers, ML-DSA-44 signs at 0.116 ms against SLH-DSA-SHA2-128f’s 11.06 ms, roughly a 95 times gap. In the firmware study, which tested the smaller and slower “s” variant of SLH-DSA rather than the “f” variant, the sign-time gap between ML-DSA-44 and SLH-DSA-SHA2-128s stretches to nearly 1,950 times, because “s” parameter sets deliberately trade signing speed for a smaller signature.

A third data point, a 2025 arXiv survey on post-quantum and quantum-safe security benchmarking, reports the same qualitative pattern across its own SLH-DSA-128s and SLH-DSA-192s measurements: signing cost runs orders of magnitude above ML-DSA while verification stays under roughly 3 ms even at the largest tested parameter sets. Verification is the one place the two algorithms get closer to each other. ML-DSA-44 verifies in 0.035 ms against SLH-DSA-SHA2-128f’s 0.680 ms, about a 19 times gap rather than a 95 times gap, because SLH-DSA’s verification only has to walk one authentication path through the hash tree rather than rebuild it.

The practical read: if your workload signs constantly (a TLS terminator, an API gateway issuing tokens), ML-DSA’s signing speed is close to mandatory. If your workload signs once and verifies constantly (a firmware image checked by millions of devices, a software update checked by every client that downloads it), the sign-time gap matters far less, because you pay it exactly once per release.

Security Foundations: Lattice Math vs Hash Functions

ML-DSA’s security rests on Module-LWE, a lattice problem that asks an attacker to recover a secret vector from a system of noisy linear equations. Module-LWE is younger than RSA or elliptic-curve math (it entered serious study in the 2000s and 2010s rather than the 1970s and 1980s), and no classical or quantum algorithm is known to solve it efficiently. That said, lattice cryptography as a field is still comparatively new, and cryptographers openly acknowledge that a structural weakness could in principle surface as the field matures.

SLH-DSA sidesteps that risk entirely by refusing to introduce a new hardness assumption. Its security reduces to the collision resistance and preimage resistance of standard hash functions, either SHA-2 or SHAKE, both of which have absorbed decades of public cryptanalytic attention and show no signs of a practical break. That’s the entire argument for keeping SLH-DSA in the standard at all: it gives organizations a signature scheme whose failure mode would require breaking a primitive far more heavily studied than any lattice problem.

Neither algorithm has a published attack that threatens real-world use as of September 2026. The choice between them isn’t “which one is currently more secure.” It’s “which failure mode are you more willing to bet against for the next 20 to 30 years,” since that’s the realistic lifespan of signatures embedded in long-lived infrastructure like firmware roots of trust or code-signing certificates.

How ML-DSA and SLH-DSA Compare to Classical RSA and ECDSA

It helps to put both post-quantum algorithms next to the signatures most production systems still run today. A typical RSA-2048 signature is 256 bytes. RSA-4096, still common on high-assurance certificate chains, produces a 512-byte signature. ECDSA over the P-256 curve, the workhorse behind most modern TLS deployments and nearly all cryptocurrency wallets, signs in roughly 64 to 72 bytes. Against that baseline, ML-DSA-44’s 2,420-byte signature looks large, running about 9.5 times bigger than RSA-4096 and roughly 34 times bigger than ECDSA P-256. SLH-DSA-SHA2-128s, at 7,856 bytes, runs over 15 times larger than RSA-4096 and well past 100 times larger than ECDSA.

Speed tells a similar story in reverse for ML-DSA. ECDSA P-256 signing on modern hardware typically completes in well under a tenth of a millisecond, often faster than ML-DSA-44’s 0.116 ms, so post-quantum signing does add measurable overhead even on the faster of the two new algorithms. That gap disappears at scale for most services, since 0.1 ms of extra signing time rarely bottlenecks a system built around network round trips measured in tens of milliseconds. SLH-DSA is the one that changes the math meaningfully: its 11 to 1,400 millisecond signing times run anywhere from 100 to over 10,000 times slower than ECDSA, a gap large enough to force architectural decisions rather than just add a rounding error.

None of this is a knock against either post-quantum algorithm. RSA and ECDSA get their compact signatures from math that Shor’s algorithm breaks efficiently on a sufficiently large quantum computer, while ML-DSA and SLH-DSA both resist that attack by design. The size and speed cost is the price of quantum resistance, and the comparison above is mainly useful for setting expectations: teams moving off RSA-4096 toward ML-DSA should plan for roughly an order of magnitude more signature bytes per connection, and teams moving any high-frequency signing path toward SLH-DSA should expect that cost to run two to four orders of magnitude higher still.

NIST Standardization Timeline and FIPS Status

Both standards trace back to the same NIST Post-Quantum Cryptography Standardization process, but they entered it at different points. CRYSTALS-Dilithium was selected as a primary signature candidate in NIST’s third-round announcement, while SPHINCS+ was originally submitted in 2017 and picked up later specifically as a conservative, structurally different backup. Both were finalized as FIPS standards on the same date, August 13, 2024: ML-DSA as FIPS 204 and SLH-DSA as FIPS 205, alongside ML-KEM (FIPS 203) for key encapsulation. All three are listed on the NIST digital signatures project page as final, approved standards for both federal and commercial use.

NIST has continued refining SLH-DSA’s parameter space since the FIPS 205 publication. A 2025 draft, NIST SP 800-230, proposes additional SLH-DSA parameter sets optimized for limited-signature use cases, capping certain keys at 2^24 signatures in exchange for smaller output. That draft status signals NIST still sees room to tune SLH-DSA for narrower deployments even though the core FIPS 205 text is locked and final.

ML-DSA has seen less post-finalization tuning because its three parameter sets already cover the standard security categories cleanly. Ecosystem work since 2024 has focused on integration rather than the algorithm itself: independent open-source implementations, including the dilithium-py library referenced in NIST’s own threshold-cryptography research, have confirmed interoperability with the official FIPS 204 test vectors.

CNSA 2.0 and Federal Migration Deadlines

The NSA’s Commercial National Security Algorithm Suite 2.0 sets the clearest deadline structure either algorithm faces today. For software and firmware signing specifically, CNSA 2.0 guidance calls for new code to support and prefer CNSA 2.0 signing algorithms, meaning ML-DSA-87 or the stateful hash-based schemes XMSS/LMS for firmware, by the end of 2025. Exclusive use, with no fallback to classical algorithms, is required by 2030 for software and firmware, and by 2033 for web browsers, servers, and cloud services.

DeadlineRequirement
End of 2025Support and prefer CNSA 2.0 signing for new software, firmware, browsers, servers, and cloud services
Jan. 1, 2027All new National Security System acquisitions must be CNSA 2.0 compliant (CNSSP 15)
Dec. 31, 2030Exclusive CNSA 2.0 use for software and firmware signing, federal agencies migrate high-value systems to PQC key establishment
Dec. 31, 2031CNSA 2.0 mandated for National Security Systems, federal agencies migrate high-value systems to PQC digital signatures
2033Exclusive CNSA 2.0 use for web browsers, servers, and cloud services
2035Complete quantum-resistant transition for National Security Systems, per NSM-10

Outside national security systems, the White House’s broader federal PQC transition strategy tells civilian agencies to migrate high-value assets and high-impact systems to NIST-approved algorithms for key establishment by December 31, 2030, and for digital signatures by December 31, 2031. Those two dates line up with the CNSA 2.0 NSS deadlines almost exactly, which suggests the federal government wants one unified transition clock rather than separate ones for classified and unclassified systems.

None of this guidance mandates SLH-DSA specifically. CNSA 2.0 names ML-DSA-87 as its preferred general-purpose signature and calls out XMSS/LMS, not SLH-DSA, for firmware. SLH-DSA’s role in most compliance frameworks is a permitted alternate, useful where an organization wants hash-based conservatism or wants to avoid the state-management burden that comes with XMSS and LMS, both of which require careful bookkeeping to avoid catastrophic key reuse.

Who’s Actually Deploying Each Algorithm in 2026

Specs and deadlines only matter if the software stack actually implements them. Here’s what has shipped as of September 2026:

  • OpenSSL 3.5.0, released April 8, 2025, added native support for ML-KEM, ML-DSA, and SLH-DSA directly in the core library, with no external provider or patch required. Debian Trixie shipped with OpenSSL 3.5.0 in August 2025, putting native PQC signing into a mainstream Linux distribution by default.
  • Cloudflare has deployed ML-DSA support for the connection between its edge network and origin servers, covering Authenticated Origin Pulls and its Custom Origin Trust Store, detailed on Cloudflare’s post-quantum cryptography documentation. The rollout ran to Free, Pro, and Business customers from May 20 to June 5, 2026, then to Enterprise customers through early July 2026. Cloudflare’s engineering team has also written publicly, in a post titled “Why we cannot wait for better post-quantum signature algorithms”, about choosing ML-DSA now rather than waiting for smaller alternatives still in research.
  • AWS KMS added ML-DSA signing in June 2025, exposing ML_DSA_44, ML_DSA_65, and ML_DSA_87 as selectable key specifications through the standard CreateKey, Sign, and Verify APIs.
  • Google Cloud KMS offers both ML-DSA and SLH-DSA signing, making it the first major cloud KMS to expose the hash-based standard alongside the lattice-based one for general customer use.
  • Bouncy Castle, the widely used Java cryptography library, added pre-hash signature forms using SHA2-512 for both ML-DSA and SLH-DSA in version 1.81, giving Java shops a path to either algorithm without a native library dependency.
  • wolfSSL documents full SLH-DSA (FIPS 205) support in its embedded TLS stack, including API calls that return the exact private key, public key, and signature size for whichever parameter set a device picks, useful for firmware where every byte of flash matters.
  • Open Quantum Safe’s liboqs, the reference prototyping library most of the above benchmarks run against, lists ML-DSA as “Tier 2 (Supported)” and SLH-DSA as “Tier 3 (Community)” in its own algorithm maturity classification, a small but telling signal of which algorithm the open-source ecosystem has prioritized hardening first.

Standards work is moving in parallel. Cloudflare’s own timeline notes that an ML-DSA certificate standard, RFC 9881, published in October 2025, and a TLS IANA codepoint for ML-DSA was registered in December 2025, both steps that make ML-DSA usable in ordinary browser-facing HTTPS rather than just internal infrastructure.

Cloud KMS Pricing: What It Costs to Run Either Algorithm

Neither AWS nor Google Cloud publishes a separate PQC pricing tier. ML-DSA and SLH-DSA keys bill under each provider’s existing asymmetric-key pricing structure, which means the real cost difference between the two algorithms shows up less in KMS line items and more in bandwidth, since SLH-DSA signatures are transferred and stored on top of whatever the KMS charges for the signing operation itself.

Cost itemAWS KMSGoogle Cloud KMS
Per-key monthly fee$1.00 per asymmetric key, per monthBilled per active key version, not per key
Active key version rateN/A (flat per-key fee)$0.000082192/hour for the first 2,000 key-version-months, then $0.003424658/hour
Request pricing~$0.15 per 10,000 requests for most asymmetric Sign/Verify operationsBilled per cryptographic operation on top of key-version cost
ML-DSA supportML_DSA_44 / 65 / 87 key specs, GA since June 2025GA support
SLH-DSA supportNot listed as a selectable key specGA support

Google Cloud KMS is currently the only major provider offering SLH-DSA as a first-class, selectable key type, which matters for any team that wants hash-based signing without maintaining its own liboqs or Bouncy Castle integration. AWS KMS covers the ML-DSA side but, based on its published key-spec list, has not extended the same managed-key treatment to SLH-DSA, so teams that need SLH-DSA signing on AWS infrastructure today are more likely to run it themselves through OpenSSL 3.5, wolfSSL, or liboqs rather than through a managed KMS call.

The hidden cost is bandwidth. A service issuing a million ML-DSA-65 signatures a month moves roughly 3.3 GB of signature data. The same volume in SLH-DSA-SHA2-128f moves over 17 GB, more than five times as much, before accounting for the larger public keys some protocols also need to transmit alongside each signature. For a TLS terminator handling millions of handshakes a day, that difference compounds fast, and it’s the real reason ML-DSA, not SLH-DSA, is the algorithm showing up in browser-facing deployments first.

5 Use Cases and Which Algorithm Fits Best

The spec sheet and benchmark numbers point toward a fairly clean split once you map them against real deployment patterns:

  • TLS certificates and mTLS handshakes. ML-DSA is the practical choice. A handshake that adds tens of kilobytes per connection for SLH-DSA signatures adds real, measurable latency at scale, while ML-DSA’s 2.4 to 4.6 KB signatures stay close enough to today’s RSA-4096 certificate chains that most middleboxes and clients handle them without special tuning. Cloudflare’s own origin-pull deployment reflects exactly this choice.
  • High-volume API and token signing (JWTs, OAuth assertions). ML-DSA again, driven by its sub-millisecond sign time. A service issuing tens of thousands of signed tokens per second cannot absorb SLH-DSA’s 11-to-1,400 millisecond signing cost without adding dedicated signing infrastructure.
  • Firmware and secure boot chains. This is SLH-DSA’s strongest case, alongside XMSS/LMS. Firmware gets signed once per release and verified millions of times on constrained devices. SLH-DSA’s sub-millisecond verification and tiny 32-to-64-byte public key fit a boot ROM’s limited flash far better than ML-DSA’s larger 1.3-to-2.6 KB public key, and the one-time signing cost, even at over a second for the smallest parameter set, is a rounding error against a release cycle measured in weeks.
  • Long-lived code-signing and CA root keys. Organizations that need a signature to remain trustworthy for 15 to 20 years lean toward SLH-DSA precisely because it introduces no new hardness assumption. A root key that signs a handful of intermediate certificates a year can absorb SLH-DSA’s size and speed costs easily, and gets hash-based conservatism in return.
  • Bandwidth-constrained IoT telemetry signing. ML-DSA wins again, but for a different reason than TLS: devices that push small sensor payloads over cellular or LPWAN links cannot afford to attach a 7.8 to 49.8 KB SLH-DSA signature to every message. ML-DSA-44’s 2.4 KB signature is still large relative to a typical sensor packet, which is why several IoT-focused implementers are watching the smaller SLH-DSA parameter sets proposed in NIST’s SP 800-230 draft for future limited-signature use cases instead.

Migration Guide: Moving From RSA/ECDSA to PQC Signatures

Neither algorithm drops into an existing RSA or ECDSA deployment without planning. The steps below reflect how OpenSSL 3.5, AWS KMS, and Google Cloud KMS all now expose these algorithms.

  1. Inventory every signing operation in scope. List TLS certificates, code-signing keys, firmware roots, and API token signers separately, since each one likely needs a different algorithm choice based on the use cases above.
  2. Confirm your crypto library version. OpenSSL needs 3.5.0 or newer for native ML-DSA and SLH-DSA support. Older versions require the Open Quantum Safe provider or a third-party patch.
  3. Pick hybrid signing during the transition window. Most 2025-2026 deployments, including Cloudflare’s, run classical and post-quantum signatures side by side rather than cutting over in one step, so clients that don’t yet understand ML-DSA or SLH-DSA still validate against the classical signature.
  4. Generate a test key pair and confirm interoperability. Use the OpenSSL command below to generate an ML-DSA-65 key pair and inspect its structure before touching production certificates.
  5. Benchmark your own workload. The numbers in this article come from liboqs reference benchmarks. Real signing latency depends on your CPU, your library version, and whether hardware acceleration is available, so measure before committing to a parameter set.
  6. Update certificate and protocol tooling for the new codepoints. The TLS IANA codepoint for ML-DSA registered in December 2025, and RFC 9881 defines the certificate format. Confirm your CA software and TLS stack both recognize these before issuing production certificates.
  7. Set an internal deadline tied to CNSA 2.0 or your compliance framework. Even organizations outside federal contracting increasingly mirror the 2030/2031 CNSA 2.0 dates in vendor contracts, so aligning your migration plan to that clock avoids a scramble later.
# Generate an ML-DSA-65 key pair with OpenSSL 3.5+
openssl genpkey -algorithm ML-DSA-65 -out mldsa65_private.pem
openssl pkey -in mldsa65_private.pem -pubout -out mldsa65_public.pem

# Generate an SLH-DSA-SHA2-128s key pair for comparison
openssl genpkey -algorithm SLH-DSA-SHA2-128s -out slhdsa128s_private.pem
openssl pkey -in slhdsa128s_private.pem -pubout -out slhdsa128s_public.pem

# Sign and verify a file with either key
openssl dgst -sign mldsa65_private.pem -out signature.bin message.txt
openssl dgst -verify mldsa65_public.pem -signature signature.bin message.txt

Pros and Cons at a Glance

ML-DSA

  • Pro: Signatures stay under 5 KB across all three parameter sets, close to RSA-4096 territory.
  • Pro: Sub-millisecond signing and verification, suitable for high-throughput TLS and API workloads.
  • Pro: Named as the primary CNSA 2.0 signature scheme, with the widest managed-KMS support (AWS and Google Cloud).
  • Con: Relies on Module-LWE, a lattice assumption with a shorter public track record than hash-function security.
  • Con: Public and private keys run larger than SLH-DSA’s, which matters on the most flash-constrained embedded targets.

SLH-DSA

  • Pro: Security reduces to hash-function collision resistance, the most heavily studied assumption in this comparison.
  • Pro: Public and private keys are tiny (32 to 128 bytes), ideal for boot ROM and constrained storage.
  • Pro: Stateless, unlike XMSS/LMS, so it avoids the catastrophic key-reuse risk that comes with stateful hash-based schemes.
  • Con: Signatures run from 7,856 bytes up to 49,856 bytes, five to twenty times larger than ML-DSA.
  • Con: Signing latency runs from roughly 11 ms up to over a second depending on parameter set, unusable for high-frequency signing.
  • Con: Managed KMS support is thinner. AWS KMS does not list it as a selectable key spec as of this writing.

The Verdict: Which Should You Choose in 2026

Pick ML-DSA as the default for anything that signs frequently or travels over a network: TLS certificates, API tokens, mTLS handshakes, and general-purpose code signing. Its 2.4 to 4.6 KB signatures, sub-millisecond sign times, and status as the CNSA 2.0 primary scheme make it the algorithm every major cloud KMS and TLS stack has prioritized first, and the data backs that prioritization up.

Reach for SLH-DSA specifically when the signing operation is rare and the trust window is long: firmware roots of trust, CA root and intermediate keys, or any signature you expect to still matter in 2045. Its cost, several kilobytes of signature and up to a couple of seconds of signing time, disappears against a release cycle measured in months, and in exchange you get a signature scheme whose worst-case failure mode requires breaking primitives with a much longer public safety record than lattice cryptography currently has.

Most organizations migrating off RSA and ECDSA in 2026 will not have to choose exclusively. NIST standardized both for a reason, and Google Cloud KMS already lets customers provision either one from the same console. The realistic path is ML-DSA everywhere signing volume matters, with SLH-DSA layered in specifically at the roots of trust where a second, structurally different assumption is worth the extra bytes.

Frequently Asked Questions

Is ML-DSA the same thing as CRYSTALS-Dilithium?

Yes. ML-DSA is the name NIST gave the standardized version of CRYSTALS-Dilithium when it finalized FIPS 204 on August 13, 2024. Any documentation referring to Dilithium after that date is describing the same algorithm now formally called ML-DSA.

Is SLH-DSA the same thing as SPHINCS+?

Yes. SLH-DSA is the standardized name for SPHINCS+ under FIPS 205, finalized the same day as FIPS 204. SPHINCS+ was originally submitted to NIST’s PQC competition in 2017.

Which algorithm is faster, ML-DSA or SLH-DSA?

ML-DSA is faster at both signing and verification in every published benchmark. Signing benchmarks from the QNSP liboqs suite put ML-DSA-44 at 0.116 ms against SLH-DSA-SHA2-128f’s 11.06 ms, roughly a 95 times gap. Verification is closer but still favors ML-DSA by a wide margin.

Do I need to deploy both ML-DSA and SLH-DSA?

Not necessarily, but many organizations do deploy both, using ML-DSA for high-volume signing and SLH-DSA for long-lived root keys where its different security assumption adds a hedge. NIST standardized both precisely so organizations have that option rather than betting everything on one hardness assumption.

When do I actually have to migrate to post-quantum signatures?

For US federal high-value and high-impact systems, digital signature migration is required by December 31, 2031, per the White House’s federal PQC transition strategy. CNSA 2.0 sets a similar 2030-2031 window for National Security Systems. Organizations outside federal contracting don’t face a hard legal deadline yet, but many are aligning internal migration plans to the same window since vendor and compliance requirements increasingly reference it.

Does OpenSSL support ML-DSA and SLH-DSA today?

Yes, natively, since OpenSSL 3.5.0 released on April 8, 2025. No external provider or patch is required, and Debian Trixie has shipped with that OpenSSL version since August 2025.

Can I use SLH-DSA for TLS certificates?

Technically yes, but almost no production TLS deployment does, because its signatures run 7,856 to 49,856 bytes and would add substantial size to every handshake. Cloudflare and other large TLS operators have prioritized ML-DSA for exactly this reason. SLH-DSA is far more common in firmware, code-signing, and CA root scenarios where signing frequency is low.

What happens if a weakness is ever found in ML-DSA’s lattice assumption?

That’s the exact scenario SLH-DSA exists to hedge against. Because SLH-DSA’s security depends only on hash-function collision resistance rather than Module-LWE, an organization that deployed SLH-DSA at its roots of trust would not need to re-key those roots even if a future breakthrough weakened lattice-based schemes. This is also why NIST kept both algorithms as final standards rather than picking a single winner.

How much bigger is a SLH-DSA signature than an ML-DSA signature, in plain terms?

At the smallest parameter sets, SLH-DSA-SHA2-128s produces a 7,856-byte signature against ML-DSA-44’s 2,420 bytes, a 3.2 times difference. At the fast end of SLH-DSA’s range, SLH-DSA-SHA2-256f reaches 49,856 bytes, over 10 times larger than ML-DSA-87’s 4,627-byte signature at the equivalent top security category.

Should a new project starting today use ML-DSA, SLH-DSA, or classical RSA/ECDSA?

For any new project handling data that needs to stay confidential or authentic for more than a few years, start with ML-DSA rather than RSA or ECDSA alone, since data captured today can be decrypted or forged retroactively once a cryptographically relevant quantum computer exists, a risk often called harvest-now-decrypt-later. Add SLH-DSA specifically for long-lived root or firmware signing keys where the extra bytes and signing latency are affordable. Pure classical RSA or ECDSA, with no post-quantum component, is no longer the recommended default for anything with a multi-year trust horizon.