When to Reach for a Non-Lattice Scheme: A Decision Framework over Size, Maturity, and Risk

Across this series the refrain has been that the lattice schemes are the efficient default and the non-lattice families are deliberate exceptions. This final article makes that judgment operational: a framework for deciding when a code-based, hash-based, or multivariate scheme earns its place over the lattice default. The answer is never that a non-lattice scheme is generally better — it is not — but that a specific axis, maximal conservatism, assumption diversity for a long-lived secret, or a size constraint the lattice profile cannot meet, occasionally dominates the decision. Naming those axes, placing each family on them, and walking a decision flow from the deployment's needs is how the choice is made responsibly rather than by fashion.

The decision axes

Four axes govern the choice among post-quantum families. The first is assumption maturity: how long and how hard the underlying problem has been studied, from the decades-old code-decoding and hash assumptions through the well-studied but younger lattice problems to the fragile multivariate constructions. The second is the size profile: the shapes of public keys, ciphertexts, and signatures, which differ enormously across families and interact with where the cost can be paid. The third is independence from lattices, the property that makes a scheme useful as a diversity hedge rather than a correlated bet.

The fourth axis is the deployment's own character: the lifetime of the secret and the stakes of its compromise. A short-lived, low-stakes secret can rest comfortably on the efficient default; a decades-long, high-stakes secret that a harvest-now-decrypt-later adversary is recording today warrants more conservatism and diversity, because the cost of being wrong is both larger and irreversible. This axis is what turns an abstract preference for diversity into a concrete decision for a particular secret.

These axes trade against one another, and no family wins all of them, which is why the choice is contextual. The lattice family is balanced but younger; the code family is conservative but bulky; the hash family is conservative but its signatures are large; the multivariate family is compact but fragile. A decision is a projection of a deployment's needs onto these axes, selecting the family whose strengths match the axis that matters most for that deployment.

The families placed on the axes

Placing each family on the axes produces a clear map. The lattice schemes are the general-purpose default: balanced small sizes, fast operations, a well-studied if younger assumption, and no independence from themselves. The hash-based signature is maximally conservative with large signatures, ideal as a durable signature anchor. The code-based key mechanisms are conservative and independent of lattices, with Classic McEliece paying a huge key for the most battle-tested assumption and HQC offering a practical kilobyte-scale standardized backup. The multivariate signatures are the compact-signature option but the least mature and highest-risk.

The table gathers this. Reading it, the pattern of when to deviate from the lattice default becomes visible: choose the code family when independence and conservatism for key establishment matter, the hash family when a durable signature must rest on the weakest assumption, and the multivariate family only when signature size is critical and immaturity is acceptable. Each non-lattice choice is a response to a specific dominating axis, not a general upgrade.

The map also shows why the lattice family remains the default. It is the only family that is simultaneously small, fast, and well-studied across both key establishment and signing; the non-lattice families each sacrifice one of these for a strength on another axis. Unless a deployment's needs make that sacrifice worthwhile, the balanced lattice profile is the right choice, which is why the framework's most common output is simply the default.

The decision flow

The decision starts from the secret's character, not the algorithm. First assess lifetime, stakes, and any hard size constraint. If the secret is durable and high-stakes — a key protecting data that must stay confidential for decades against a future quantum attacker — then assumption diversity and conservatism matter, and a non-lattice hedge is warranted alongside or instead of the lattice scheme: the standardized code-based key mechanism for key establishment, or the hash-based signature for a durable signing anchor. If the secret is ordinary — short-to-medium lifetime, routine stakes — the lattice default is the right answer and no deviation is needed.

Two side branches refine this. If signatures must be extremely small and the application can tolerate a younger assumption and a large key, a conservative multivariate signature is worth considering for that narrow role, chosen with the caution the previous article urged. And if a hard size constraint rules out a family — a megabyte key that cannot fit, or a large signature that breaks a budget — that constraint prunes the options directly, often leaving the lattice scheme or the more compact code variant as the only viable choice.

Framing the decision this way keeps the algorithm subordinate to the requirement and makes the common case fast: most secrets are ordinary, so most decisions land on the lattice default, and the non-lattice families are reached for consciously when durability, diversity, or size makes them worth their cost. The flow ensures those exceptions are deliberate rather than accidental.

Combining families for the highest stakes

For the most consequential durable secrets, the strongest posture is not to choose one family but to combine two independent ones. Just as the migration series described a classical-plus-post-quantum hybrid, a dual-family post-quantum combination — a lattice key mechanism and an independent code-based one, their shared secrets merged through a robust combiner — remains secure as long as either family stands. This hedges the exact systemic risk the series opened with: a lattice break would not compromise a secret also protected by a code-based scheme, and vice versa.

The cost is additive: two key establishments, two sets of material, and the combiner logic, which is why this is reserved for the highest-stakes, longest-lived secrets rather than applied everywhere. But for a master key protecting a decades-long archive, or the root of an agent-identity system meant to endure, the additive cost is a small price for independence from any single assumption family failing. The robust-combiner discipline from the migration series applies directly: concatenate the secrets with the transcript through an approved derivation, with independent randomness.

Combining families is the logical endpoint of the diversity argument. Where a single independent backup hedges against the primary failing, a live combination of two families hedges against either failing while both are in use, at the price of running both. It is the most conservative option the portfolio offers, appropriate precisely where the stakes and the lifetime make the strongest possible hedge worth its cost.

Recommendations, and the agent portfolio

The framework resolves into a small set of defaults. Use the lattice schemes for the overwhelming majority of key establishment and signing — they are the balanced, standardized default. Reserve the hash-based signature for durable, high-assurance signing anchors, the code-based key mechanism for durable or high-stakes key establishment where independence from lattices is wanted, and the multivariate signature only for niche size-critical signing with a short-lived key and eyes open to its fragility. For the highest-stakes durable secrets, combine a lattice and an independent non-lattice family. And keep the whole portfolio crypto-agile so any of these can be adopted or swapped without rework.

The unifying principle is proportionality: match the family to the secret's lifetime, stakes, and size constraints, defaulting to lattice and spending the cost of conservatism, diversity, or a specialized size profile only where the deployment genuinely calls for it. This is the same disciplined, requirement-first reasoning that ran through the signature-selection and migration-methodology articles, applied to the question of which hardness family to trust.

For autonomous AI systems the portfolio maps cleanly onto the workload. Protect high-volume agent and model traffic with the efficient lattice schemes. Protect durable, high-stakes assets — long-retention training-data archives, model-weight encryption keys, agent-identity roots meant to endure — with a non-lattice hedge, the standardized code-based key mechanism for encapsulation and the hash-based signature for signing, and consider a dual-family combination for the most critical of these given the harvest-now-decrypt-later horizon. Use multivariate signatures, if at all, only for constrained short-lived agent messaging where their tiny signatures decisively help. The result is a diverse, agile cryptographic portfolio that spends efficiency where volume lives and conservatism and independence where durability and stakes demand it — exactly the balance the whole beyond-lattices series has argued for.

Practitioner Toolkit

Copy-paste, strictly defensive artifacts you can use today. Nothing here attacks a real system.

family_selection:
  default: lattice
  durable_high_stakes_kem: code_based_hqc
  durable_signature_anchor: hash_slh_dsa
  highest_stakes_durable: dual_family_lattice_plus_code
  size_critical_short_lived_signing: conservative_multivariate
axes: [maturity, size, independence, lifetime_stakes]
portfolio:
  crypto_agile: required

Glossary

Assumption maturity

How long and how hard a hardness problem has been studied; code and hash are most mature, lattice younger but well-studied, multivariate least.

Size profile

The characteristic key, ciphertext, and signature sizes of a family, which determine where its cost can be paid.

Independence (from lattices)

The property that a family's assumption does not share a break with lattices, making it a genuine diversity hedge.

Secret lifetime and stakes

How long a secret must stay confidential and how costly its compromise would be; long, high-stakes secrets warrant more conservatism and diversity.

Dual-family combination

Running a lattice and an independent non-lattice scheme together with a robust combiner, secure as long as either family stands.

Proportionality

Matching the family to the secret's requirements, defaulting to lattice and paying for conservatism, diversity, or a size profile only when justified.

References

1. NIST IR 8545, Status Report on the Fourth Round of the NIST PQC Standardization Process (2025)
2. McEliece, A Public-Key Cryptosystem Based on Algebraic Coding Theory (JPL DSN Progress Report, 1978)
3. Beullens, Breaking Rainbow Takes a Weekend on a Laptop (CRYPTO, 2022)
4. NIST FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard (2024)
5. NIST FIPS 205, Stateless Hash-Based Digital Signature Standard (2024)