Lattice-Based vs Hash-Based vs Code-Based Signatures

01Performance benchmarks are the wrong axis

When NIST evaluated PQC signature candidates, the optimization targets were speed, signature size, key size, and implementation difficulty. Those are reasonable targets for the median use case, which is signing TLS handshakes or web traffic where bandwidth and latency are budget items.

The median use case is also where the security stakes are bounded. A broken TLS signature affects sessions and certificate trust until the scheme is replaced. The cryptographic incident is bounded to that migration window. Migration to a new scheme is tractable at the protocol level.

Crypto holders, by contrast, sign transactions that move durable wealth. A broken signature scheme adopted by a major blockchain potentially compromises every coin still controlled by exposed public keys from that scheme. Coins migrated to safer outputs before the break would be unaffected. The economic exposure scales with adoption duration. The time horizon for “this scheme needs to stay secure” is measured in decades, well beyond the connection lifetimes that drove NIST’s benchmarks.

That changes the optimization function. The signature size that’s too big for TLS becomes acceptable for a transaction that holds value for 20 years. A few extra milliseconds of signing time is a cheap trade for assumption durability when the cryptography needs to outlive multiple processor generations.

02Lattice won the first wave on performance

Lattice-based signatures perform well across every benchmark NIST evaluated. Fast signing, fast verification, compact signatures by post-quantum standards, and engineering practices that already exist for production deployment. ML-DSA-65 signatures are 3.3 KB and verification runs in well under a millisecond on commodity hardware. FN-DSA signatures are smaller still, closer to 700 bytes at the standard parameter set.

The math underneath (Module Learning With Errors for ML-DSA, NTRU-based problems for FN-DSA) has held up to three decades of cryptanalysis. That’s the durability case for lattices. The cryptographic community has tried to break these problems and has gotten incremental results, never the kind of breakthrough that would invalidate the whole family.

The durability case has a credible counter-argument. M-LWE is younger than the hash functions underlying SLH-DSA, by a factor of about two. Cryptographers have been attacking SHA-256-style hash functions since the 1990s without finding the kind of structural weakness that would change the security picture. They’ve been attacking lattice problems for less than half that time. Confidence in a hard problem grows logarithmically with the years it survives, and lattice math has fewer years on the clock.

03Hash-based wins on assumption durability

Hash-based signatures are built on the assumption that a hash function (typically SHA-256 or SHAKE-256) is collision-resistant and preimage-resistant. That’s it. The entire security argument reduces to whether the hash function is broken.

The hash function isn’t broken. SHA-256 has been the target of sustained academic and adversarial cryptanalysis since its standardization in 2001. The closest anyone has come to a structural attack was the SHA-1 collisions published in 2017, and SHA-1 was already considered deprecated by then. SHA-256 has not had a comparable result, and the structural reasons it differs from SHA-1 are well-understood.

That gives hash-based signatures a security argument as old and well-tested as anything in cryptography. SLH-DSA (FIPS 205) is the most recent and most convenient, since it’s stateless and doesn’t require tracking which key indices have been used. XMSS and LMS (RFC 8391 and RFC 8554 respectively) are older but offer significantly smaller signatures and faster signing times, at the cost of stateful key management.

The trade-off has always been signature size. SLH-DSA signatures range from 8 KB to 49 KB depending on parameter set. XMSS and LMS signatures are smaller (2 to 4 KB range) but require the wallet or application to track exactly which key indices have already signed something, because reusing a key index in either scheme breaks security.

For bandwidth-constrained applications, those sizes are prohibitive. Long-horizon high-security applications treat them as an acceptable tax.

04Code-based signatures are still a research project

Code-based cryptography has a longer history than lattice cryptography. The McEliece encryption scheme, published in 1978, remains unbroken. That’s an even older durability case than hash functions.

Signatures specifically have been harder. The original code-based signature scheme, CFS (Courtois-Finiasz-Sendrier, 2001), produced impractical signature sizes and verification times. The schemes that followed had their own issues, and several code-based candidates submitted to NIST’s main PQC competition were broken during the review process.

NIST’s additional-signatures call (announced 2023) ran multiple evaluation rounds. Earlier rounds included code-based candidates like CROSS, LESS, MEDS, and SDitH. The Round 3 list announced in May 2026 advanced SDitH and dropped several earlier code-based candidates. These are interesting on durability grounds because they sit on different assumptions from both lattices and hashes. They’re early on production-readiness grounds because none has the deployment track record of the established options.

Here’s the summary. Code-based signatures have the right assumption-durability story but no standardized workhorse to point at. If NIST’s additional-signatures process produces a viable code-based standard in the next few years, the conversation expands to four families. Until then, it’s a two-family choice with code-based as a research-stage option.

05What standards bodies should prioritize

The conventional wisdom that emerged from NIST’s first wave is a hierarchy with ML-DSA at the default position. SLH-DSA gets the conservative-fallback slot, and FN-DSA fills the small-signature niche. That hierarchy is correct for the median use case.

For the highest-stakes long-horizon use cases (base-layer blockchain signature schemes), the hierarchy should flip. The default should be hash-based, with SLH-DSA in the workhorse role and XMSS or LMS available as higher-performance options for applications that can manage statefulness. Lattice schemes are better placed as performance specialists. The assumption durability case for lattices isn’t strong enough yet for cryptography that has to survive multiple decades of adversarial improvement.

Blockchain protocols sit firmly in the long-horizon category. A Bitcoin or Ethereum signature has to remain unforgeable for the entire lifetime of the coins it controls. That lifetime is measured in decades for any holder who isn’t actively trading. A signature scheme that’s been stress-tested for fifteen years is a categorically different bet than one stress-tested for fifty.

06The recommendation?

“

A signature scheme stress-tested for fifteen years is a categorically different bet than one stress-tested for fifty.

---

This article is educational and does not constitute security or investment advice.

// FAQ

What are the three post-quantum signature families?

Lattice-based (ML-DSA, FN-DSA), hash-based (SLH-DSA, plus the older stateful XMSS and LMS), and code-based (still under evaluation, with SDitH advancing in NIST’s additional-signatures process).

Which is best for a blockchain?

On the durability axis that matters for chain-lifetime exposure, hash-based, because its only assumption is a hash function that has survived 25+ years of attack. Lattice is faster and smaller, but its math has had fewer years of scrutiny.

Why doesn't signature size settle it?

Size matters for bandwidth-limited uses like TLS. For a transaction that must stay secure for decades, a larger signature is an acceptable tax for a more durable security assumption.

Is lattice-based cryptography unsafe?

No. ML-DSA and FN-DSA have held up to three decades of cryptanalysis and are NIST standards. The point is only that hashes have roughly twice the track record, which matters most for the highest-stakes, longest-lived keys.

When will code-based signatures be usable?

Not yet. The assumption-durability story is strong (McEliece encryption from 1978 is unbroken), but there is no standardized, deployable code-based signature. SDitH advanced in NIST’s Round 3 in May 2026; a usable standard is still a few years out.