up:: The New Standards MOC

Lattice vs Code-Based vs Hash-Based

Lattice, code-based and hash-based cryptography are the three mathematical foundations underneath every NIST post-quantum standard, and they divide the work unevenly. Lattices are the only family that does both key establishment and signatures, which is why they carry the primary standards. Code-based cryptography does key establishment alone. Hash-based cryptography does signatures alone, and rests on the single best-understood assumption in the field.

The reason more than one family is standardized has nothing to do with any of them being suspect. It is that the primary standards for both jobs rest on the same broad lattice assumptions, and a future advance against lattices would weaken several of them at once.

The short version:

• They cover different jobs. Lattices produce both a KEM and signatures, code-based cryptography produces KEMs only, and hash-based cryptography produces signatures only. No family besides lattices answers the whole question.
• They sit at different points on the confidence curve. Hash-based security rests only on a hash function, the most-studied primitive in cryptography. Code-based cryptography has the longest unbroken scheme history, going back to 1978. Lattice problems have been studied since the 1990s, which makes them the youngest of the three assumptions.
• The size costs land in different places. Lattice artifacts are larger than the elliptic-curve ones they replace but small enough for everyday protocols. Classic McEliece public keys run to hundreds of kilobytes. SLH-DSA signatures run from 7,856 to 49,856 bytes.
• Only one non-lattice KEM was standardized. NIST selected the code-based HQC on March 11, 2025 as the backup to ML-KEM, and Classic McEliece and BIKE were studied and not selected.
• A break in each costs something different. A lattice break would reach ML-KEM, ML-DSA and FN-DSA together. A code-based break would reach a backup nobody has deployed broadly. A hash-based break would mean a hash function had fallen, which would be a much larger problem than post-quantum cryptography.

Think of three ways to build a vault door. The first is machined from a new alloy that performs beautifully in every test, is light enough to hang on an ordinary frame, and has been in production for about 30 years. The second is cast iron of a recipe from 1978 that nobody has ever cut through, and it weighs so much the frame has to be rebuilt around it. The third is a design that uses only a fastener whose failure modes have been documented for decades, and it works only on the hinges rather than on the door itself. A building that fits all three is not indecisive. It is a building where a flaw in one alloy does not open every door at once.

What is the difference between lattice, code-based and hash-based cryptography?

The difference is the hard mathematical problem each family stakes its security on, and that choice determines what each family can build. Lattice cryptography rests on the difficulty of finding short or close vectors in high-dimensional grids, which supports both encryption-style and signature-style constructions. Code-based cryptography rests on the difficulty of decoding random linear error-correcting codes, which supports key encapsulation. Hash-based cryptography rests only on a hash function staying collision- and preimage-resistant, which supports signatures.

None of the three is broken, and none is a replacement for the others. They occupy different roles in one portfolio of standards, and the portfolio exists because concentrating every standard on one assumption would make a single cryptanalytic advance expensive across an entire estate.

What is lattice-based cryptography?

Lattice-based cryptography secures data on the hardness of geometry problems in high-dimensional grids, chiefly the Shortest Vector Problem and the Closest Vector Problem, reached in practice through the noise-hardened Learning With Errors problem and its module variant. Shor’s algorithm has nothing to attack here, because lattice hardness is geometric rather than number-theoretic and carries none of the periodic structure Shor’s needs.

It became the mainstream family because it was the only candidate that did everything the transition required at a workable cost: it covers both jobs, it is fast on ordinary hardware, and it held up under a multi-year NIST evaluation.

What is code-based cryptography?

Code-based cryptography secures data on the syndrome decoding problem, which asks you to recover an original message from a random-looking linear code corrupted with errors. The general version of that problem is NP-hard, and the founding scheme, the McEliece cryptosystem of 1978, has never been practically broken.

The family produces KEMs and has no widely standardized signature scheme, so it addresses the confidentiality half of the transition and contributes nothing to authentication. Its defining cost is size, historically very large public keys.

What is hash-based cryptography?

Hash-based cryptography builds signatures out of one-time signature schemes combined through a Merkle tree, so that a single published root vouches for a whole stack of one-time keys. Every operation in the construction is a hash, which means security reduces cleanly to the hash function’s collision- and preimage-resistance with no algebraic structure anywhere for future cryptanalysis to exploit.

There is no hash-based KEM, because hash functions do not naturally support key encapsulation. The family signs, and only signs.

Lattice vs code-based vs hash-based at a glance

Dimension	Lattice	Code-based	Hash-based
Hard problem	Shortest and Closest Vector Problems, via Module-LWE and Module-SIS	Syndrome decoding of random linear codes, NP-hard in the general case	Collision- and preimage-resistance of a hash function
Foundation dates from	Studied since the 1990s	McEliece cryptosystem, 1978	Merkle signatures, built on hash functions studied for decades
Key establishment	Yes, ML-KEM	Yes, HQC	None. No hash-based KEM exists
Signatures	Yes, ML-DSA and FN-DSA	None widely standardized	Yes, SLH-DSA and stateful XMSS and LMS
Finalized NIST standards	FIPS 203 and FIPS 204, both finalized August 13, 2024; FIPS 206 in draft	None finalized. HQC selected March 11, 2025, draft expected around 2026, final expected 2027	FIPS 205, finalized August 13, 2024; NIST SP 800-208 for the stateful schemes, October 2020
Representative sizes	ML-KEM-768 public key 1,184 bytes	Classic McEliece public key hundreds of kilobytes up to roughly a megabyte, with a very small ciphertext	SLH-DSA signatures 7,856 to 49,856 bytes, public keys 32 to 64 bytes
Speed profile	Fast on mainstream hardware; compute is rarely the bottleneck	Adding errors is trivial for the sender; the cost is bytes rather than cycles	Signing and verification are hash operations; the cost is signature size
Known structural caveat	Module and ring structure that makes it practical is, in principle, extra surface for a future attack	HQC is selected and not yet finalized; BIKE carries a non-negligible decryption-failure probability	Stateful schemes break if a one-time key signs twice, which is why they live in HSMs
Implementation risk	Constant-time noise handling and rejection-sampling loops in signing need real hardening	The BIKE bit-flipping decoder has been sensitive to timing side channels	Stateless SLH-DSA carries no state burden; stateful schemes require reliable state tracking
Role in the portfolio	The primary default for both jobs	The non-lattice backup for key establishment	The conservative anchor for long-lived and firmware signing
What a break would reach	ML-KEM, ML-DSA and FN-DSA together, since all three draw on lattice assumptions	HQC, a backup not yet broadly deployed	A hash function itself, which would be a far wider problem than post-quantum cryptography

Sources on this table, each verified against the primary document.

Source: NIST FIPS 203 and NIST FIPS 204, both finalized August 13, 2024, for the lattice standards and the ML-KEM-768 public-key size.

Source: NIST FIPS 205, Table 2, August 2024, for the SLH-DSA signature and public-key sizes.

Source: NIST IR 8545, Status Report on the Fourth Round of the NIST PQC Standardization Process, March 2025, for “The only key-establishment algorithm that will be standardized is HQC.”

Source: NIST, “NIST Selects HQC as Fifth Algorithm for Post-Quantum Encryption”, March 11, 2025.

Source: NIST SP 800-208, Recommendation for Stateful Hash-Based Signature Schemes, October 2020.

How do they actually differ?

1. Job coverage is the difference that shaped the whole standards portfolio. Public-key cryptography does two things, and only lattices produce strong schemes for both. Code-based cryptography reached the standards process with KEMs and no signature, hash-based cryptography with signatures and no KEM. That asymmetry is why the primary defaults for confidentiality and authentication are both lattice-based, and it is also why the concentration exists that the other two families are there to offset.

2. The confidence curve runs opposite to the practicality curve. Hash-based security rests on the assumption cryptographers trust most and produces the largest signatures. Lattice security rests on the youngest of the three assumptions and produces artifacts small enough for everyday protocols. Code-based cryptography sits between them on confidence and, in the Classic McEliece case, at the extreme end on size.

3. Size costs land on different parts of a system. Lattice growth shows up in certificates, handshakes and storage across the whole estate. Classic McEliece inverts the usual profile with an enormous public key and a tiny ciphertext, which disqualifies it wherever the public key ships on every handshake and makes it workable where a static key is provisioned once out of band. SLH-DSA growth lands on individual signatures, which matters for high-volume signing and rarely for a firmware image.

4. Only lattice cryptography carries a structural caveat about its own optimization. Plain LWE and SIS are conservative and heavy, and the ring and module variants that made the family fast enough to standardize add algebraic structure that is, in principle, additional surface for a future attack. That is a watched question rather than a known weakness, and it has no analogue in the hash-based case, where there is no structure to add.

5. The failure modes at the operational layer are different in kind. A lattice implementation fails through side channels in noise handling and rejection sampling. A stateful hash-based deployment fails if a one-time key ever signs twice, which is catastrophic and is the reason XMSS and LMS live inside hardware that can guarantee state. A code-based deployment using BIKE carries a small non-zero chance that a valid message fails to decapsulate at all.

Where do they agree?

1. None of them is threatened by Shor’s algorithm. Shor’s needs the hidden periodic structure that factoring and discrete logarithms have. Lattice geometry, syndrome decoding and hash functions all lack it, which is the property that makes all three post-quantum in the first place.

2. All three absorb Grover’s algorithm through parameter sizing rather than through redesign. Grover offers a quadratic speedup on brute-force search, which is a real discount rather than a break, and every family’s standardized parameter sets are chosen with quantum search already priced in.

3. All three cost more bytes than what they replace. Every post-quantum family is larger on the wire than the elliptic-curve cryptography it succeeds, so the integration work across all of them lands on bandwidth, protocol handling, certificate size and storage rather than on processing time.

4. All three came through the same NIST evaluation. The standards were selected through one multi-year public process, so the differences between families reflect deliberate portfolio decisions rather than separate standards efforts that happened to converge.

5. All three depend on crypto-agility to be useful as a portfolio. Standardizing several foundations only helps an organization that can actually change algorithms without re-architecting, which is why agility appears as a requirement alongside the algorithms in every major mandate.

Why did NIST standardize more than one family?

Because the primary standards for both jobs rest on the same broad lattice assumptions, and that is a concentration as well as an efficiency. A future cryptanalytic advance against lattices, classical or quantum, could weaken ML-KEM, ML-DSA and FN-DSA at the same time, leaving an organization that deployed only lattice cryptography to re-migrate everything at once.

NIST stated the reasoning plainly when it selected HQC: “We want to have a backup standard that is based on a different math approach than ML-KEM,” and HQC “will serve as a backup defense in case quantum computers are someday able to crack ML-KEM.”

That a post-quantum candidate can genuinely fall is documented rather than hypothetical. The isogeny-based scheme SIDH/SIKE was a serious NIST contender until an ordinary classical computer broke it in 2022, after which it was withdrawn. Lattices show no comparable crack, and that history is why keeping independent foundations available is the prudent instinct.

Source: NIST, March 11, 2025; W. Castryck and T. Decru, “An Efficient Key Recovery Attack on SIDH,” 2022, IACR ePrint 2022/975.

When is each family the right answer?

Lattice cryptography is correct for the general case. ML-KEM is the finalized default for key establishment and ML-DSA for general-purpose signing, and they are what a migration deploys first because they are finalized, they are fast, and the library and validation ecosystem is built around them.

Code-based cryptography is correct as the non-lattice reserve for key establishment. HQC is the selected backup and is not yet a finalized standard, which makes it something to design for rather than to deploy broadly today. Classic McEliece is correct in the narrow case where a static public key can be provisioned once out of band and only its very small ciphertext crosses the link afterward.

Hash-based cryptography is correct where a signature has to be trusted for a very long time. Firmware and boot signing, roots of trust, and durable trust anchors all sign infrequently enough that size is not the bottleneck and need confidence measured in decades. NSA CNSA 2.0 singles out the stateful schemes LMS and XMSS specifically for software and firmware signing rather than for general-purpose use, and stateless SLH-DSA fills the same conservative role without the state burden.

Source: NSA CNSA 2.0, Announcing the Commercial National Security Algorithm Suite 2.0, September 2022; the algorithm requirements themselves are in NSA, “The Commercial National Security Algorithm Suite 2.0 and Quantum Computing FAQ,” CSI ver. 2.1, December 2024, CNSA 2.0 table, media.defense.gov, because the announcement page states that the advisory exists and lists none of the algorithms.

Why do people confuse them?

Coverage tends to describe post-quantum cryptography as one thing with one set of algorithms, so the families read as interchangeable brands of the same product. Three specific confusions follow from that.

The first is assuming any family can do any job, which produces plans that reach for a code-based scheme to solve a signing problem or a hash-based scheme to solve key establishment. The second is reading maturity as a ranking, so that hash-based cryptography’s stronger assumption is heard as an instruction to prefer it, when its lack of a KEM and its signature sizes make it unsuitable as a general default. The third is treating every algorithm studied by NIST as a NIST standard, which is how Classic McEliece and BIKE get described as standards when only HQC will be standardized from the fourth-round key-establishment candidates.

Common misconceptions

1. “One family is more secure than the others.” They rest on different assumptions with different amounts of study behind them, and none of the standardized schemes has been broken. Hash-based cryptography carries the strongest long-term confidence and the narrowest job description, which is a tradeoff rather than a ranking.

2. “Code-based cryptography is the new default.” The finalized primary KEM is ML-KEM. HQC is the selected code-based backup, still awaiting a final standard, and it should never be a reason to delay an ML-KEM migration.

3. “All the NIST post-quantum standards are lattice-based.” FIPS 203, FIPS 204 and the draft FIPS 206 are. FIPS 205 is deliberately hash-based, and HQC is code-based, so the portfolio carries three foundations on purpose.

4. “Grover’s algorithm breaks hash-based signatures.” Grover halves a hash function’s effective security margin through a quadratic search speedup, and the schemes absorb that by choosing hash output sizes accordingly. That is a manageable discount rather than the total break Shor’s algorithm delivers against RSA and elliptic-curve cryptography.

5. “The big keys make code-based cryptography insecure.” Large public keys are a deployment cost rather than a weakness, and in the one profile that fits them, a static key provisioned out of band with a tiny ciphertext on the wire, the size becomes workable.

6. “Stateless SLH-DSA replaced stateful XMSS and LMS.” Both are current NIST-backed standards for different jobs. The stateful schemes remain far more compact, which is what firmware signing wants when the signer can manage state safely.

Questions people ask

Which post-quantum family should I be deploying? Lattice-based, through ML-KEM for key establishment and ML-DSA for general-purpose signatures. Those are the finalized standards with the most mature ecosystem, and the other families occupy backup and long-lived-signing roles rather than replacing them.

Why is there no code-based signature scheme? No code-based signature reached wide standardization through the NIST process. The family’s constructions are naturally suited to key encapsulation, so signatures in the standards portfolio come from lattice and hash-based mathematics.

Why is there no hash-based KEM? Hash functions do not naturally support key encapsulation, which needs a trapdoor structure that a hash function deliberately lacks. The family produces signatures only.

Which family has been studied longest? Hash functions are the most-studied primitive in cryptography, which gives hash-based signatures the strongest assumption. Measured by the age of a specific unbroken scheme, code-based cryptography leads, with the McEliece cryptosystem dating to 1978. Lattice problems have been studied since the 1990s.

If lattices might be weakened, why are they the default? Because they are the only family that covers both jobs at practical sizes and speeds, and no lattice standard has been broken. The response to the concentration is a standardized non-lattice backup and crypto-agility, rather than declining to deploy the finalized defaults.

Are Classic McEliece and BIKE NIST standards? No. Both were fourth-round candidates that NIST studied and did not select. Of the fourth-round key-establishment candidates, only HQC will be standardized.

What happened to the fourth family? Isogeny-based cryptography was a serious contender through SIDH/SIKE until a classical attack broke it in 2022 and it was withdrawn. It is the clearest evidence that a promising post-quantum assumption can fail, and the reason a portfolio of independent foundations is worth maintaining.

Do I need to run more than one family? The finalized defaults are lattice-based and sufficient to deploy today. Keeping a non-lattice option reachable is what the standardized backup exists for, and whether that matters for a given system depends on how long its data has to stay confidential and how expensive a second migration would be.

Does the choice of family change how I integrate the algorithms? Mostly it changes sizes. All three arrive through cryptographic libraries, TLS stacks and HSM firmware rather than being implemented directly, so the integration work is sizing, testing and protocol handling, and the families differ in how many bytes they add and where.

---

The map is free and I keep it that way. When the question becomes which of these foundations belongs where across an actual estate and its protocols, that’s the work I do at LaMarr Labs.

Go deeper

• Lattice-Based Cryptography, Code-Based Cryptography and Hash-Based Cryptography for each family in full
• ML-KEM vs HQC for the two standardized KEMs compared directly
• ML-DSA vs SLH-DSA vs FN-DSA for the three signature standards compared
• Shor vs Grover for the two quantum algorithms that shape all three families
• Crypto-Agility for the capability that makes a portfolio of foundations useful
• The New Standards MOC for the whole standards picture

Last verified 2026-08-10 · Maintained by Addie LaMarr, LaMarr Labs.