NIST leans toward seed-only keys for HQC in draft FIPS 207

NIST plans to require a seed-only private key format in the forthcoming Initial Public Draft of FIPS 207, the standard for HQC-KEM, and is asking the post-quantum community whether anyone opposes that choice.

Angela Robinson, writing for the FIPS 207 team, said the agency is inclined to make the seed the sole permissible format and to disallow caching of expanded keys. The rationale is that expansion offers little performance gain over simply storing the public key alongside the seed for decapsulation. The approach deliberately differs from FIPS 203 (ML-KEM), which permits both seed and expanded forms. NIST cited post-publication feedback that a single format is preferable to two.

Early reaction largely favored a single portable format. Several implementers called the seed-only rule an improvement over the dual-format situation that has complicated ML-KEM and ML-DSA deployments. Bas Westerbaan and Deirdre Connolly supported seeds as the external format but argued that implementations should still be free to cache intermediate values after loading a key; an outright ban on such caching, they said, would block ordinary two-step APIs and minor optimizations even when the security impact is negligible.

D. J. Bernstein opposed seed-only standardization. He pointed to software-security arguments that favor a precomputed decapsulation format over a raw seed, while noting that the mere decision to pick one format (rather than two) is already an improvement given that HQC is breaking compatibility anyway.

Others stressed that NIST should define exactly one byte-string encoding for the seed and leave broader import/export and caching questions to protocols and libraries. The draft is expected shortly; NIST has invited further comment before the text is locked.