FN-DSA, HQC, and algorithms beyond the first three standards.

A cryptographic portfolio needs both usable standards and credible alternatives. The alternatives deserve serious study, but research maturity, standardization status, implementation assurance, and protocol readiness have to be assessed independently — never inferred from each other. This chapter covers Falcon-derived FN-DSA's trapdoor sampling, HQC's code-based construction, Classic McEliece as an instructive reference point for what selection actually means, and the ongoing additional-signature evaluation (MAYO, SQIsign, FAEST, and others) — with explicit standardization-status boundaries kept visible throughout, since that's exactly where this topic goes wrong in casual conversation.

1. What this part adds

Parts 7–9 covered the three finalized NIST PQC algorithms: ML-KEM, ML-DSA, and SLH-DSA. This chapter explains why work continues beyond them. You'll learn the design motivations behind Falcon-derived FN-DSA, the code-based KEM HQC, and several additional-signature families — and practice reading a selection report without treating "selected" as equivalent to "completed standardization."

2. A status map with explicit boundaries

The fourth-round report, NIST IR 8545, documents the actual selection reasoning. It's more informative than a popularity ranking because it weighs security confidence, performance, implementation characteristics, and the existing portfolio's needs together. A decision not to select an algorithm is not automatically a declaration that it's broken — Classic McEliece is the clearest example of this in the whole standardization process (§6). See NIST IR 8545 and the NIST PQC project material.

3. Falcon's objective: a short signature with a trapdoor

Falcon follows a hash-and-sign approach over NTRU lattices, using the trapdoor-sampling framework associated with Gentry, Peikert, and Vaikuntanathan. A public relation defines many possible vectors associated with a hashed message; the private key provides special information for efficiently sampling an appropriately short vector. Without that trapdoor, finding a suitable short preimage should be hard.

In a schematic ring relation, a public polynomial \(h\) and message-derived target \(c\) are associated with a short pair \((s_1,s_2)\) satisfying \(s_1 + s_2 h \equiv c \pmod q\). Verification checks the relation and a norm bound. The private key enables generating such short pairs with the required distribution, while the public key never reveals the useful short basis.

For an insecure scalar illustration: take \(q=17\), \(h=5\), \(c=9\). The pair \((-1,2)\) satisfies \(-1+2{\cdot}5=9\) and has squared Euclidean norm 5. Many larger pairs satisfy the modular equation too — the shortness requirement is what gives the verification condition real substance. Real Falcon uses high-dimensional polynomial structure and carefully selected bounds, not this toy scalar relation.

NTRU structure gives a compact representation of a lattice and its trapdoor. It does not make every algorithm bearing the NTRU name identical — encryption schemes, KEMs, and signatures can use related mathematical structures while having entirely different security goals, parameters, and implementation requirements (Part 5 §3.1). See the Falcon specification.

4. Why sampling is the difficult part

A naive signer might choose the closest convenient lattice point using its secret basis directly. The resulting signatures can then reveal statistical information about that basis over repeated observations — a serious, historically real vulnerability class in trapdoor signature schemes. A secure trapdoor sampler must produce exactly the specified distribution, so the output doesn't disclose the trapdoor through subtle biases an attacker can accumulate over many signatures.

Falcon uses fast Fourier sampling. Fourier-domain calculations exploit polynomial structure to make the recursive sampling process efficient. This FFT involves numerical floating-point representations used specifically in sampling — it should not be conflated with the finite-field NTT arithmetic introduced for ML-KEM and ML-DSA (Part 6 §11). Both are transforms, but their correctness and implementation concerns differ substantially.

5. Compactness is real; benchmark portability is limited

The Falcon project page reports submission-era public-key/signature sizes of 897/666 bytes for Falcon-512 and 1,793/1,280 bytes for Falcon-1024. These illustrate the bandwidth motivation clearly — they are not asserted here as final FN-DSA wire sizes, and Falcon's encodings and signature-format choices must be fully understood before comparing byte counts against any other scheme. See the Falcon project page.

The same page reports performance for a specified Intel Core i5-8259U system with TurboBoost disabled. Those measurements describe that specific implementation and environment — they cannot be combined with an ARM laptop measurement of ML-DSA to conclude any universal speed ratio between the two. Compiler, CPU features, key representation, operation boundaries, and benchmark date all affect the comparison (Part 14 covers this discipline fully).

A constrained verifier may value compact signatures and fast verification while delegating signing to a powerful, protected service elsewhere. Another device may need to sign locally without suitable floating-point arithmetic support at all. The same algorithm can fit the first role well and be genuinely difficult in the second — evaluate the signer and verifier separately rather than assigning one blanket "embedded suitability" label to the whole scheme.

A security review should examine Gaussian sampling, secret-dependent control flow, memory accesses, fault responses, and key-generation behavior. Review also needs to cover serialization and API initialization — the Falcon project's historical API advisory illustrates that bugs can occur outside the central mathematical algorithm entirely, even when standardization test vectors exercise another interface correctly.

6. Coding theory: recovering a message from controlled errors

Error-correcting codes add redundancy so a receiver can recover data after some bits change. Let a codeword be \(c\) and an error vector \(e\); the received word is \(r = c+e\) over a finite field (binary addition is XOR). A decoder uses the code's structure to recover \(c\) exactly when the error pattern falls within its supported region.

For a toy repetition code, encode bit 0 as 000 and bit 1 as 111. Receiving 101 is one bit away from 111, so majority decoding correctly returns 1. Receiving 001 instead returns 0 — too many errors can cross the decision boundary entirely. This code is trivial to decode and provides zero public-key security on its own; it only demonstrates correctness under a bounded error model.

A parity-check matrix \(H\) gives another useful representation. A valid codeword satisfies \(Hc^T=0\). The syndrome of \(r\) is \(Hr^T = He^T\), so it depends only on the errors (Part 4 §10). Finding a low-weight error with a given syndrome is the syndrome-decoding viewpoint — the weight counts nonzero positions, unlike the Euclidean norms used in Falcon's example above.

Cryptographic code-based constructions arrange for legitimate recovery while an attacker faces a genuinely hard decoding-related problem. The public structure, secret information, error distribution, and transformation into a full KEM all determine the actual security claim. "Decoding is hard" must always be qualified — some codes and error ranges are intentionally easy by design, while cryptographic instances are specifically chosen to resist known decoding methods.

7. HQC's role in the portfolio

HQC stands for Hamming Quasi-Cyclic. Its construction uses binary polynomial operations, sparse vectors, and error-correcting codes. Quasi-cyclic structure gives a compact way to represent certain linear operations — the legitimate decryption path cancels shared terms and decodes a message with remaining noise, exactly the same cancellation shape as Part 6's LWE example, while the surrounding KEM transformation supplies the stronger chosen-ciphertext-oriented construction on top.

The code used to correct errors here is not simply a hidden efficient decoder in the same architectural sense as Classic McEliece. HQC combines a public decoding component with a noisy algebraic construction whose security relies on structured decoding assumptions. This distinction matters when comparing families — shared coding terminology does not imply identical secret-key structure or failure analysis between the two.

NIST selected HQC in March 2025 specifically to complement ML-KEM with a different mathematical foundation. The announcement described a final standard expected in 2027 — that's a published plan, not a current finalization claim, and it is not a reason to postpone migration work that can already use finalized standards today. See NIST's selection announcement.

Algorithmic diversity reduces dependence on one set of mathematical assumptions, but it does not guarantee independent failures (Part 5 §10). Implementations may share hash code, random generators, memory allocators, providers, and deployment infrastructure. A robust portfolio identifies which dependencies are actually different and which remain common across supposedly independent alternatives.

8. HQC sizes and implementation questions

The HQC project site, as retrieved for this chapter, lists current project encodings of a 2,241-byte public key and 4,433-byte ciphertext for HQC-1; 4,514 and 8,978 bytes for HQC-3; and 7,237 and 14,421 bytes for HQC-5. These are project snapshots, not finalized NIST parameter tables — version-pin any experiment, because specifications and encodings can and do change during standardization. See the HQC project site.

These sizes show why bandwidth and buffering deserve attention. A protocol designed around a roughly one-kilobyte KEM ciphertext (like ML-KEM-768, Part 7 §3) may need larger handshake buffers, different fragmentation behavior, or more expensive retransmissions for an alternate construction like this. That doesn't make the alternative unsuitable — it makes the transport budget a genuinely measurable design constraint that needs to be checked explicitly, not assumed.

Decryption-failure behavior requires particular scrutiny in code-based schemes specifically. Correctness probability, decoder timing, chosen-ciphertext handling, and error reporting all interact. A decoder that leaks information through variable work or unusual failure modes can undermine an otherwise well-studied primitive — study the complete KEM and its current analysis rather than extracting just the encryption core for standalone application use.

9. Classic McEliece as a reference point

Classic McEliece builds on a long-studied code-based lineage using binary Goppa codes and a secret decoding capability. Its major practical tradeoff is a very large public key relative to many modern KEMs, paired with genuinely compact ciphertexts. That asymmetry can be attractive when a key is provisioned once and reused for many exchanges, but difficult in protocols that transmit fresh keys frequently.

NIST IR 8545 explains why HQC was selected from the fourth round and why Classic McEliece was not selected in that particular decision. The outcome should never be paraphrased as "all code-based alternatives lost" or "McEliece was broken" — neither is true. Selection is a portfolio and deployment decision made after weighing multiple factors together, not a cryptanalytic verdict.

10. Additional signatures: a continuing evaluation

NIST's round-three additional-signature page groups candidates by construction. It still carries a heading referring to nine selected candidates, while explicitly marking HAWK withdrawn — a careful status table must preserve that withdrawal instead of repeating the headline number as a count of currently active submissions (§2).

The roster includes multivariate schemes such as MAYO, QR-UOV, SNOVA, and UOV; MPC-in-the-head approaches such as MQOM and SDitH; isogeny-based SQIsign; and symmetric-primitive-oriented FAEST. These categories explore different combinations of public-key size, signature size, computational cost, and underlying assumptions (Part 5 §6–8). Their presence in a round is an invitation to continued analysis — not a general deployment endorsement of any one of them.

MPC-in-the-head signatures derive noninteractive proofs from simulated multiparty computations. Multivariate signatures use systems of polynomial equations with special secret structure. SQIsign uses isogeny-based mathematics in a signature construction distinct from the broken SIDH/SIKE key-exchange design (Part 5 §8) — the SQIsign project provides its current papers and specifications for specialist study. See the round-three roster and SQIsign.

The SIKE break remains a useful lesson worth repeating here: a concrete construction can fail even when a broader mathematical area remains active. Conversely, the survival of another isogeny construction does not "repair" SIKE. Track exact assumptions, leaked auxiliary information, and protocol design specifically — not a family name treated as either a guarantee or a permanent disqualification.

11. Diversity needs a failure model

Suppose a service supports ML-KEM and a future standardized HQC profile. If it chooses exactly one mechanism per connection, the portfolio offers migration flexibility, but each individual connection still depends entirely on whichever mechanism was chosen. If a reviewed hybrid construction combines both, the security claim can be genuinely different — but supporting two names in a config file is not equivalent to combining their secrets securely (Part 5 §10's diagram applies directly here).

The same distinction applies to signatures. Accepting either of two signatures can improve compatibility while leaving an attacker free to target whichever accepted path is weaker. Requiring both signatures can strengthen a particular acceptance policy but increases availability and interoperability requirements. The binding between the signed message, algorithm identifiers, and both public keys must be explicitly specified — attaching two unrelated signature files does not automatically achieve a robust composite construction on its own.

These decisions should be made through a reviewed protocol profile. An emergency migration plan can identify a supported alternate implementation, a compatible key-distribution path, and a tested policy switch without designing a brand-new cryptographic combiner from scratch — that's useful agility even before simultaneous hybrid use is actually appropriate for a given system.

12. Moving an experiment toward a deployable component

A laboratory evaluation should first establish deterministic inputs for official test-vector reproduction, plus independent randomized functional tests. Then test malformed encodings, cross-implementation exchange, memory limits, and failure handling. Record whether the implementation targets a submission version, a draft, or a final standard — that distinction belongs in the test report and artifact name itself, not just tribal knowledge.

The next stage tests the actual protocol binding and operational environment. Can every intended verifier parse the algorithm identifier? Can a key-management service generate, protect, back up, and retire the key? Can observability identify the selected mechanism without exposing secret material? Can a version upgrade distinguish an old experimental encoding from the eventual standardized one?

Only after those questions have real evidence should throughput or compactness drive a deployment decision. A fast primitive behind an unsupported certificate profile is not an interoperable identity system. Conversely, an algorithm that isn't yet ready for production can still be an excellent research exercise, as long as its scope and status stay explicit throughout.

Takeaways

• FN-DSA/FIPS 206 and HQC are selected, not finalized — treat any submission-era size or performance number as illustrative, not as the eventual standardized encoding.
• Falcon's trapdoor sampling must produce the exact specified distribution, or repeated signatures can statistically leak the secret basis — this is why fast Fourier sampling and floating-point discipline matter as much as the underlying NTRU lattice problem.
• HQC and Classic McEliece are both "code-based" but structurally different — shared terminology doesn't imply identical secret-key structure, failure analysis, or size profile.
• "Not selected" is a portfolio decision, not a cryptanalytic verdict — Classic McEliece's exclusion from the 4th-round selection says nothing about whether it's broken.
• The SIKE lesson generalizes: one construction's break (SIDH/SIKE) doesn't indict an entire mathematical family (isogenies) — track exact assumptions and exposed information, not family names.
• Two algorithm names in a negotiation list is not the same as a reviewed hybrid combiner. Real "secure if either survives" behavior needs an explicit, analyzed construction — not just configuration flexibility.

References & further reading

• NIST PQC project material · NIST IR 8545 (4th-round report) — §2, the status map's primary sources.
• Falcon specification · Falcon project page — §3–5.
• NIST — HQC selection announcement · HQC project site — §7–8.
• NIST round-three additional-signature roster — §10.
• SQIsign project — §10.