A "family" in PQC is a way to organize mathematical assumptions — it is not a product recommendation, and two constructions sharing a family label can have wildly different security arguments, wire costs, and implementation risks. This chapter builds a comparison across lattices, code-based, hash-based, multivariate, MPC-in-the-head, and isogeny constructions that preserves those differences instead of flattening them into one "post-quantum" bucket. It ends with the more important practical question: when does adding a second algorithm actually buy you security diversity, versus just adding code, interfaces, and bugs without a real security benefit?
1. Objectives and prerequisites
Part 4 introduced vectors, polynomial rings, noise, and the three security games. Here we use that vocabulary to understand the major construction families at a structural level. You'll learn to compare algorithms within the same cryptographic role, distinguish family-level intuition from a concrete mathematical assumption, and interpret both successful standardization and failed candidates without drawing conclusions broader than the actual evidence supports.
Our records service needs both key establishment and update signatures — it cannot replace a KEM with a signature scheme just because the signature happens to have fewer bytes; those solve different problems entirely (Part 2 §6). Its public gateway, a constrained embedded device, and an offline signing service also carry genuinely different workloads. A sensible family map starts from those roles, before ever discussing mathematical elegance or a performance leaderboard.
2. Start with the job, then the assumption
A KEM establishes shared secret material. A signature authenticates a message under a verification key. Hashes and symmetric encryption continue supporting both underneath. Comparing a KEM ciphertext's size against a signature's size, without naming their roles first, is like comparing the size of a door key against the length of a shipping receipt — both are numbers, but the numbers answer completely different questions.
Within one role, compare security category, implementation maturity, and workload fit. The same mathematical family can support multiple roles, while some families are currently used mainly for signatures in active standardization. A shared label like "lattice-based" does not make two interfaces interchangeable — an application's serialization, key storage, protocol profile, and error handling all bind it to one concrete construction, not to the family in the abstract.
NIST's portfolio includes the final ML-KEM, ML-DSA, and SLH-DSA standards, continuing Falcon/FN-DSA and HQC work, and a separate additional-signature evaluation process — these are genuinely different maturity levels, and this chapter's comparison (dated September 2026) does not assign final-standard status to every named scheme it discusses. See the NIST PQC overview.
3. Lattice-based cryptography
A lattice can be viewed as the set of all integer combinations of a set of basis vectors. In high dimensions, finding suitably short vectors, or recovering hidden structure from noisy observations, can be genuinely computationally difficult. Cryptographic constructions turn carefully defined lattice-related problems into key establishment or signatures. Part 6 derives the geometry and arithmetic in full, rather than leaving "high-dimensional grid" as the entire explanation.
ML-KEM uses Module-LWE-related structure: public noisy polynomial equations connect to secret values (Part 4 §5). ML-DSA uses module-lattice assumptions in a signature construction built around challenges, bounded responses, and rejection conditions. Both benefit from structured polynomial arithmetic, but their operations, moduli, distributions, and security arguments differ substantially — shared implementation vocabulary between the two does not justify copying a parameter choice from one into the other. See FIPS 203 and FIPS 204.
Structure helps reduce representation size and accelerate multiplication (via the NTT, Part 6). It also defines a more specific assumption than a completely unstructured lattice problem would be — security analysis has to account for that added structure explicitly. A reduction proof under certain conditions, and the best currently-known concrete attacks, provide complementary evidence; neither can be replaced by the slogan that "all lattice problems are hard."
From an engineering perspective, lattice implementations require careful sampling, modular arithmetic, encoding, and constant-time handling of secrets throughout. Fast vectorized code can be very attractive, but it has to preserve the exact arithmetic and leakage requirements of the specification — a mathematical construction can remain perfectly sound while one particular compiled implementation of it leaks secret information through timing (Part 13).
3.1 Falcon shows diversity within lattices
Falcon's design uses NTRU lattices and a trapdoor sampling approach, with fast Fourier techniques supporting the signing operation. Its compact signatures illustrate a genuinely different point in the lattice tradeoff space than ML-DSA occupies. That benefit comes paired with a considerably more demanding sampling implementation and real numerical-precision considerations — sharing the "lattice" label with ML-DSA does not make the two signers equally easy to implement correctly. See the Falcon project page.
The project page provides submission-era specifications and implementation results, valuable for learning the design — but final FN-DSA requirements have to come from the eventual final standard once it publishes. The current NIST record still describes this standardization work as ongoing, so this course distinguishes "Falcon design details" from any claim about a finalized FIPS 206.
For an update-signing system specifically, a smaller signature may matter enormously when millions of constrained devices need to download it. A centralized, carefully-controlled signing service might tolerate more implementation complexity in exchange. Another system that signs every interactive request has entirely different priorities. The same algorithm characteristic can be a decisive advantage in one workload and completely irrelevant in another.
4. Code-based cryptography
Error-correcting codes add structure so a legitimate receiver can recover information despite transmission errors. Code-based cryptography instead uses decoding problems as a source of computational hardness, with constructions designed so secret information enables an operation an attacker cannot efficiently reproduce. The distinction between "a code used for communication reliability" and "a code used as a cryptographic hardness assumption" (Part 4 §10) is essential and easy to blur.
HQC's stated foundation involves quasi-cyclic syndrome decoding — it's a code-based KEM selected as an additional option beyond ML-KEM specifically for its mathematical diversity, worth studying even where another construction wins on a particular benchmark. NIST's selection report frames this explicitly as a portfolio decision, not a universal victory on every engineering axis. See the HQC project page and the NIST fourth-round report.
The engineering work here includes efficient binary field operations, error sampling, decoding, and careful failure-path behavior. Large key/ciphertext objects can affect memory, transport, and storage independently of raw operation time. A system that distributes one public key and performs many encapsulations against it has a very different amortization profile from one that transmits a fresh key for every short-lived interaction.
5. Hash-based signatures
Hash-based signatures build authentication purely from carefully composed hash operations. A one-time signature can expose selected secret values whose hashes are already committed inside a public key. Merkle trees connect many such commitments to one compact root. More elaborate constructions layer these building blocks together to provide a practical, reusable signing interface.
SLH-DSA descends from SPHINCS+ and combines FORS with a hypertree of one-time-signature structures. Its small public keys come paired with substantially larger signatures than the most compact lattice choices. The SHA2/SHAKE and small/fast parameter variants expose an explicit, deliberate size-versus-work tradeoff — "based on hashes" does not reduce the full security argument down to one generic collision-resistance claim, the actual tree and one-time-signature structure matter a great deal. See FIPS 205 and the SPHINCS+ framework paper.
Stateful hash-based signatures are a separate operational category entirely. Schemes covered by SP 800-208 require correct state management to avoid ever reusing one-time signing material. Restoring an old snapshot, or running unsynchronized replicas of the same signing key, can silently violate that requirement and catastrophically break security. A replicated signing service has to treat its state as security-critical, not merely as a recoverable performance cache. See SP 800-208.
Statelessness (as in SLH-DSA) removes that particular state-maintenance contract — but not every lifetime or usage bound. The draft SP 800-230 limited-use SLH-DSA parameters (Part 1 §8) make this especially visible: their proposed size/verification tradeoff still comes with an explicit signature-count limit. Part 9 studies the tree structures and this state-versus-count distinction in full detail. See the draft SP 800-230.
6. Multivariate approaches
Multivariate public-key constructions work with systems of polynomial equations over finite fields. A public map can be evaluated efficiently, while secret structure supports an operation like finding a suitable preimage. The hoped-for asymmetry here isn't simply that polynomial equations "look complicated" — the public system specifically has to avoid revealing any exploitable structure to an attacker, which is a much harder design goal than it sounds.
A trapdoor that makes signing efficient can also leave behind relationships that cryptanalysis exploits directly. The hardness of a generic random equation system therefore does not automatically prove the security of a structured public key produced by a specific scheme — public keys, transformation layers, and the exact distribution of equations all belong squarely inside the security analysis, not outside it.
The additional-signature process is the right place to inspect current candidate-specific status and documentation for this family. This chapter deliberately does not assign one size or performance number to the entire multivariate family — some constructions spend many bytes on public keys, while others use different compression or structural choices entirely. A useful table points to a versioned candidate rather than inventing an average "multivariate signature." See the NIST candidate records.
7. MPC-in-the-head and proof-derived signatures
Another route begins with proving knowledge of a secret. Imagine a computation that checks a public statement using a hidden witness. A proof system lets a prover convince a verifier without ever directly revealing that witness. Turning a suitable interactive protocol into a noninteractive signature requires a carefully analyzed challenge-generation transformation and message binding — this step is where a lot of subtle security proofs actually happen.
MPC-in-the-head is an intuition for constructing such proofs: the prover simulates several parties jointly evaluating a computation, commits to their individual views, and reveals a challenge-selected subset so the verifier can check consistency without ever learning the entire secret. Repetition count and soundness parameters affect both how convincing the proof is and how much data has to be transmitted.
This is a high-level family description, not a complete signature scheme. The commitment construction, challenge distribution, transcript encoding, witness relation, and full security model all determine the actual result. Using a hash to generate a challenge does not automatically make an arbitrary interactive protocol into a secure signature — especially against quantum adversaries and the queries they're allowed to make in a formal security proof.
The engineering profile often involves many hash, commitment, and verification operations, plus potentially large transcripts. Different candidates make genuinely different tradeoffs here. NIST's additional-signature records provide the controlling candidate versions and should always be checked before quoting a key size or performance number. These approaches are valuable for algorithmic diversity, not a license to treat experimental schemes as deployment-ready standards.
8. Isogenies: a lesson in precise conclusions
An isogeny is a structure-preserving map between elliptic curves. Isogeny-based constructions explore problems genuinely different from the discrete logarithm on a fixed curve. Sharing elliptic-curve vocabulary with classical ECC does not make the underlying assumptions identical — and it also does not make every isogeny construction interchangeable with every other one.
The distinction is visible in current research: SQIsign appears in NIST's Round 3 additional-signature roster. Its compact objects and complex signing procedure represent another, genuinely different set of tradeoffs, and it remains a candidate rather than a final NIST signature standard. Discussing it requires its own dedicated assumptions and analysis — not an inference from either SIKE's failure or classical ECC's decades of maturity. See SQIsign and the NIST roster.
9. A comparison that keeps its units
The following table uses representative constructions and qualitative size profiles — these are not equal-security benchmark results. Exact standardized encodings appear in the dedicated algorithm chapters (Parts 7–10), where public keys, private keys, ciphertexts, and signatures are kept in separate columns rather than blurred together.
| Family / representative | Assumption | Role | Object-size profile | Maturity |
|---|---|---|---|---|
| Module lattices: ML-KEM | Module-LWE-related | KEM | Kilobyte-scale keys/ciphertexts | FIPS 203, final |
| Module lattices: ML-DSA | Module-lattice signature | Signature | Kilobyte-range keys/signatures | FIPS 204, final |
| Hash-based: SLH-DSA | Domain-separated hash constructions | Signature | Tiny public keys; much larger signatures | FIPS 205, final |
| NTRU lattices: Falcon | Trapdoor sampling over NTRU | Signature | Compact signatures vs. ML-DSA | FN-DSA ongoing |
| Codes: HQC | Quasi-cyclic syndrome decoding | KEM | Multi-kilobyte keys/ciphertexts | Selected, ongoing |
| Multivariate candidates | Structured polynomial systems | Mainly signatures | Candidate-specific; PK often dominates | Research/candidate |
| Proof-derived candidates | Witness knowledge + commitments | Signatures | Candidate-specific transcript cost | Research/candidate |
| Isogenies: SQIsign | Isogeny-related | Signature | Compact keys and signatures | Additional-sig candidate |
The final-standard rows are grounded in FIPS 203–205; the Falcon/HQC/SQIsign rows in their own project specifications; the candidate rows in NIST's current process records cited above. A broad size profile is useful for orientation but is insufficient by itself to dimension a real packet buffer or choose a certificate format — that needs the exact standardized encoding from the relevant chapter.
10. Diversity is not the same as redundancy
If two components share an assumption, an unexpected attack on that assumption may affect both simultaneously. A portfolio spanning genuinely different mathematical foundations can reduce dependence on any one line of cryptanalytic progress. But adding an algorithm also adds code, interfaces, tests, operational procedures, and possible new implementation defects — diversity has real costs that need to be justified against an actual threat model, not adopted reflexively.
Fig. 1 — Only the third column actually reduces dependence on one line of cryptanalysis. The first two look like diversity on an architecture diagram but share a common failure mode underneath.
A hybrid construction is one way to combine components, but composition itself needs its own security argument (Part 11 covers this in depth for TLS). Merely storing two keys, or selecting whichever algorithm happens to be fastest at runtime, does not automatically give "secure if either survives" behavior — the combiner function, authentication binding, negotiation policy, and error handling together determine whether that goal is actually achieved.
Likewise, two libraries implementing the same standard can help with differential testing without providing any mathematical diversity at all — they may share source code, design assumptions, or even the same bugs. Conversely, two mathematically independent families may still both depend on the exact same flawed random generator underneath. A dependency graph needs to distinguish mathematical, implementation, and operational common causes as three separate rows, not one.
11. Worked selection discussion
Suppose the records service has an online API and a firmware-release signer. For the API, a standardized hybrid TLS group may provide an interoperable key-establishment path through a maintained library. The team should measure the actual negotiated groups, handshake expansion, and failure rates in production — it should not replace its entire TLS stack with a novel KEM merely because a candidate has an attractive paper benchmark that was never independently reproduced.
For firmware signing, the team should instead count verification operations, signature-distribution frequency, bootloader memory limits, trust-anchor update capability, and recovery requirements. A larger signature may be entirely acceptable if updates are infrequent. A stateful scheme may be unsuitable if the signing key is ever replicated without a proven state-management design (§5). A compact experimental signature may still be unacceptable if the device can't safely migrate away from it when its specification eventually changes.
Now add diversity as an explicit requirement. The team might evaluate a hash-based signature option alongside a lattice signature, rather than choosing two different lattice implementations and calling the result "assumption diversity" (§10). Whether it actually deploys both depends on verifier policy and the system's supported certificate profiles. The selection document should explicitly say which failure scenario the second option is meant to address — not just "diversity" as an unexamined virtue.
No new benchmark is required to reason through these qualitative differences. A benchmark becomes necessary only once the decision genuinely depends on CPU, memory, bandwidth, or latency limits at your actual scale. Part 14 defines a fair benchmarking methodology and explains why comparing results measured on different hardware can obscure the very tradeoff you're trying to investigate.
12. Learning exercise: classify before you compare
Take a proposed cryptographic dependency and fill in six fields: role, exact scheme/version, assumption, standardization state, implementation provenance, and operational constraints. If one field is genuinely unknown, record it as unknown rather than inferring it from another field — a repository simply calling a feature "post-quantum" does not fill in all six of these.
Then write one sentence beginning: "This component protects … against … provided that …." For example: a KEM contributes to confidentiality under specified assumptions when its public key and surrounding protocol are correctly handled end to end. That sentence structure exposes missing authentication and key-lifecycle conditions far more effectively than any algorithm-name checklist ever will.
Finally, identify the evidence that could actually change the decision: a new standard publishing, a cryptanalytic result, a side-channel finding, an interoperability test failure, or a real workload measurement. This turns algorithm selection into a reviewable engineering decision with explicit revision triggers — rather than a permanent, unexamined preference for one mathematical family.
Does the SIKE break mean every isogeny-based signature is broken?
No (§8). Conclusions have to follow the attacked construction and the specific information it exposed — SIDH/SIKE's break doesn't extend to SQIsign or other isogeny constructions with different designs.
Do two independent ML-KEM libraries provide different hardness assumptions?
No (§10). They can provide valuable implementation diversity for differential testing, but both still implement the exact same underlying mathematical construction and share its assumption.
Why can a larger signature sometimes be the right engineering choice?
Distribution frequency, verifier constraints, security requirements, and implementation maturity can all matter more than minimizing one object's byte count (§11) — SLH-DSA's much larger signatures are a deliberate, reasonable tradeoff in the right workload.
Is candidate selection equivalent to a final, interoperable standard?
No (§2, §6). Specifications and integration profiles can still change materially between selection and final publication — Falcon/FN-DSA and HQC are both selected but still standardizing as of this writing.
Takeaways
- Start from the job (KEM vs. signature), not the mathematical family — comparing object sizes across roles is comparing answers to different questions.
- Six PQC families exist with genuinely different assumptions: lattices, codes, hash-based, multivariate, MPC-in-the-head/proof-derived, and isogenies — each with its own maturity level, from finalized FIPS standards to active research candidates.
- A shared family label doesn't mean interchangeable interfaces. ML-KEM and ML-DSA are both "lattice-based" but have entirely different operations, moduli, and security arguments.
- The SIDH/SIKE break is a lesson in precise conclusions — it broke one specific construction's exposed information, not "isogeny cryptography" as a family.
- Diversity is not redundancy. Two implementations of the same standard, or two math families sharing one flawed RNG, don't reduce your actual dependence on a single line of cryptanalysis — genuine diversity needs independent math and independent operational dependencies.
- Selection is a reviewable decision, not a permanent preference — record role, scheme/version, assumption, standardization state, provenance, and constraints explicitly, plus what evidence would change the call.
References & further reading
- NIST — PQC project overview — §2, the full standardization portfolio.
- FIPS 203 · FIPS 204 · FIPS 205 — §3, §5, the three finalized standards.
- Falcon project — §3.1.
- HQC project · NIST IR 8545 (4th round report) — §4.
- SPHINCS+ framework paper · SP 800-208 · draft SP 800-230 — §5.
- NIST Round 3 additional-signature roster — §6–8, candidate status.
- Castryck & Decru — An Efficient Key Recovery Attack on SIDH — §8.
- SQIsign project — §8.