Upcoming FIPS 207 - Key format

[Robinson, Angela Y. (Fed)]

Dear All,

 

NIST is preparing to release the FIPS 207 (HQC-KEM) Initial Public Draft soon and wanted to announce our current plan regarding the key format.  NIST is leaning toward specifying that the only format to be used is the seed.  Caching expanded keys would not be allowed as there is minimal performance benefit to doing so (compared to just storing the standard encoding of the public key in addition to the seed when doing decaps) . This is a different approach from FIPS 203 which allows for both the seed and the expanded key formats.   Our current inclination is a result of the feedback NIST received after the publication of FIPS 203 that one key format was preferable to two.

 

NIST would like to hear thoughts on the matter, especially if there are any opposed to the standardization of seeds as the only permissible key format in FIPS 207.

 

 

Kind regards,

Angela on behalf of the FIPS 207 Team

---

Angela Robinson, PhD

Mathematician

Cryptographic Technology Group

National Institute of Standards and Technology

 

[Bas Westerbaan]

Hi Angela,

Seed as the only portable format is great.

Many libraries including for ML-DSA and ML-KEM use a two-step API where first the key is loaded into memory and intermediate values (such as the fully expanded A) are cached after which operations can be performed. For HQC such a two-step API would also make sense. The "no caching" clause shouldn't forbid this.

Best,

 Bas

--
You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.
To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/PH8PR09MB982319A0A2F2B7945C45594C8ED52%40PH8PR09MB9823.namprd09.prod.outlook.com.

[Scott Fluhrer (sfluhrer)]

I agree, seed would be preferable.

What would be greatly preferable would be just one allowed format, rather than two, be it seed or expanded.  Allowing two formats is a mess with ML-KEM and ML-DSA - let's avoid that.

---

From: 'Bas Westerbaan' via pqc-forum <pqc-...@list.nist.gov>
Sent: Monday, August 3, 2026 8:23 AM
To: Robinson, Angela Y. (Fed) <angela....@nist.gov>
Cc: pqc-forum <pqc-...@list.nist.gov>
Subject: Re: [pqc-forum] Upcoming FIPS 207 - Key format

To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CAMjbhoULOsAHDZiAeMnKXv2DxNCYcCCGFfHy2tJN1NFacpQiAg%40mail.gmail.com.

[Tim Hudson]

If you allow more than one format, then please make it mandatory to support all the formats.

It is always preferable to have only a single defined format - and what that format represents is not relevant.

Thanks,

Tim.

--

[D. J. Bernstein]

'Robinson, Angela Y. (Fed)' via pqc-forum writes:
> NIST would like to hear thoughts on the matter, especially if there
> are any opposed to the standardization of seeds as the only
> permissible key format in FIPS 207.

Yes. The last section of

https://web.archive.org/web/20260725191703/https://03283664099418252878.googlegroups.com/attach/aa2d2617e405/kem.pdf?part=0.0.1&view=1&vt=ANaJVrG49626Wd1S3wLbqmwUU0Hd2xTdcjcmLi4OarP59o48I8qFmbRKhwntZvswmoKCpELT2NT0cE0r0fj6qDlCqcJIC8yO2zT2gX85NONxfpwgJQY7zeI

covers four software-security arguments for using a format that
precomputes data used for dec rather than just a seed.

The third software-security argument is qualitatively different from the
others, since it's about a disadvantage of allowing seeds as a second
format in a situation where there's already a precomputed format. In the
case of HQC, my understanding is that NIST is breaking compatibility
anyway, so the third argument is simply in favor of picking one HQC
format (which is what NIST now says it's planning to do), and isn't
specifically in favor of any particular format.

The first, second, and fourth software-security arguments favor
precomputed format. Earlier sections of the document cover flaws in
various arguments for seeds.

---D. J. Bernstein

[John Mattsson]

Hi Angela,

Great to hear that the FIPS 207 (HQC-KEM) IPD will be published soon.

My view is that FIPS 207 should specify that HQC-KEM.KeyGen() outputs (ek, dk = seed). As Bas states, any caching decisions should be left to the implementation, unless there are significant security consequences. Defining portable key formats is mostly a protocol and application-layer concern rather than something NIST should specify in the algorithm standard.

Cheers,

John Preuß Mattsson

[Scott Fluhrer (sfluhrer)]

I would disagree with the last part "Defining portable key formats is mostly a protocol and application-layer concern rather than something NIST should specify in the algorithm standard."

People look to NIST when selecting the portable key formats, which span both protocols and crypto implementations.  Rather than the various parties trying to pick (and end up with incompatible requirements between different implementations), it'd be better if NIST just picked one which everyone could design to.

In any case, the IPD will already specify the format of a signature and a public key; I don't see it as unreasonable if it also specifies the import/export format of a private key.

---

From: 'John Mattsson' via pqc-forum
Sent: Monday, August 3, 2026 9:12 AM
To: pqc-...@list.nist.gov

Subject: Re: [pqc-forum] Upcoming FIPS 207 - Key format

--
You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.

To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/AS4PR07MB88258790E9A9B4F88C48219B89D52%40AS4PR07MB8825.eurprd07.prod.outlook.com.

[D. J. Bernstein]

'Scott Fluhrer (sfluhrer)' via pqc-forum writes:
> In any case, the IPD will already specify the format of a signature
> and a public key; I don't see it as unreasonable if it also specifies
> the import/export format of a private key.

I assume you meant ciphertext rather than signature, since HQC is a KEM.
Separately from that, can you please clarify what you mean by "import"
and "export"?

For example, are you saying NIST should specify the output format of
GPG --export-secret-keys? OpenSSL's EVP_PKEY_get_raw_private_key? The
result if a user logs into a web-hosting page and clicks a "download TLS
private key" button? The "import"/"export" terminology seems confusing.

---D. J. Bernstein

[Blumenthal, Uri - 0553 - MITLL]

On 8/3/26, 12:06, "pqc-...@list.nist.gov" <pqc-...@list.nist.gov> wrote:
> ... can you please clarify what you mean by “import"  and "export"?

>

> For example, are you saying NIST should specify the output format of

> GPG --export-secret-keys? OpenSSL's EVP_PKEY_get_raw_private_key? 

If NIST publishes a GPG and/or OpenSSL standard — then yes.

[John Mattsson]

To clarify what I think, I think FIPS 207 should specify exactly how the seed dk is formatted as a byte string. This format will be in the test vectors. I think that is enough if FIPS 207 avoid talking about alternative formats. I don't see what NIST could/should do more

Sent from Commodore VIC-20

---

From: pqc-...@list.nist.gov <pqc-...@list.nist.gov> on behalf of D. J. Bernstein <d...@cr.yp.to>
Sent: Monday, August 3, 2026 6:06 PM
To: pqc-...@list.nist.gov <pqc-...@list.nist.gov>

Subject: Re: [pqc-forum] Upcoming FIPS 207 - Key format

--
You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.

To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/20260803160547.2239113.qmail%40cr.yp.to.

[Deirdre Connolly]

> NIST is leaning toward specifying that the only format to be used is the seed.  

This great, I highly support it.

> Caching expanded keys would not be allowed as there is minimal performance benefit to doing so (compared to just storing the standard encoding of the public key in addition to the seed when doing decaps) . 

I don't know if this should be disallowed— even if the performance benefit to caching is small compared to say expanding the A matrix in ML-KEM, having just gone through the exercise of squeezing out almost every bit of performance in my KEM implementation, having an outright disallowal in the standard to such an optimization would be disappointing. Having a statement similar to those regarding the seed formats in FIPS 203, 204 ('this material should be treated with the same care as key material' or something to that effect) would seem to suffice.

> This is a different approach from FIPS 203 which allows for both the seed and the expanded key formats.   Our current inclination is a result of the feedback NIST received after the publication of FIPS 203 that one key format was preferable to two.

Correct, having a single format is preferred over having ~two, and having that single format be the seed format is preferred over the expanded format seen in the HQC submissions. 

Another benefit of the seed format is stronger binding properties for the KEM for those that care, although IIRC the HQC team already made some changes to their submission key format regarding the salted FO transform to improve those from where they were— seed format is even better.

 

--

You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.

To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/PH8PR09MB982319A0A2F2B7945C45594C8ED52%40PH8PR09MB9823.namprd09.prod.outlook.com.

[Scott Fluhrer (sfluhrer)]

Ummm, yes, public key and ciphertext (my bad)

As for private key import and export, I'm talking about how it is moved to/from the crypto implementation. Of course, if the higher level application wants to ASCII armor it, that's its business, just like if a higher level application wants to ASCII armor its (doubling checking here to avoid the same mistake) ciphertext...

_______________________________________
From: pqc-...@list.nist.gov on behalf of D. J. Bernstein
Sent: Monday, August 3, 2026 12:05 PM

To: pqc-...@list.nist.gov
Subject: Re: [pqc-forum] Upcoming FIPS 207 - Key format

'Scott Fluhrer (sfluhrer)' via pqc-forum writes:

---D. J. Bernstein

--

You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.

To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/20260803160547.2239113.qmail%40cr.yp.to.

[Scott Fluhrer (sfluhrer)]

I just noticed this:

"Caching expanded keys would not be allowed as there is minimal performance benefit to doing so (compared to just storing the standard encoding of the public key in addition to the seed when doing decaps)"

That is contrary to the current NIST philosophy on crypto implementations, which is "we don't care about the internals; if it passes the ACVP tests, it's good enough for us"

Will there be additional code inspection to make sure that no nefarious expanded key caching is happening?  If the implementation holds just one private key, does keeping around that one expanded key count as caching?  Would keeping around that one expanded key add a security risk?  If it doesn't, then I see no reason to explicitly prohibit it.

---

From: 'Robinson, Angela Y. (Fed)' via pqc-forum <pqc-...@list.nist.gov>
Sent: Monday, August 3, 2026 8:13 AM
To: pqc-forum <pqc-...@list.nist.gov>
Subject: [pqc-forum] Upcoming FIPS 207 - Key format

--

You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.

To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/PH8PR09MB982319A0A2F2B7945C45594C8ED52%40PH8PR09MB9823.namprd09.prod.outlook.com.

[COSTA Graham]

THALES GROUP LIMITED DISTRIBUTION to email recipients

I think NIST needs to be very clear as to what they mean by 'caching' which is going to mean different things to different implementers. 

I think fixing formats for key transfer between modules helps simplify interfaces and protocols which has been the main focus of discussions linked to FIPS-203.

I think fixing rules for how modules can store keys internally to the module goes too far and is inconsistent with all other NIST cryptographic specifications.  In some cases - 'cache' are more about having keys ready to use in the right place (i.e. right memory - often in or close to hardware) and right time, and less about avoiding efforts to expand.

---

From: 'Scott Fluhrer (sfluhrer)' via pqc-forum <pqc-...@list.nist.gov>
Sent: Monday, August 3, 2026 18:52
To: pqc-forum <pqc-...@list.nist.gov>; Robinson, Angela Y. (Fed) <angela....@nist.gov>
Subject: [pqc-forum] Re: Upcoming FIPS 207 - Key format

To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/PH3PPFA3FE8A23F8020292A1821C3F2D7A6C1D52%40PH3PPFA3FE8A23F.namprd11.prod.outlook.com.

[Joost Renes]

Hi Angela,

 

Thank you for the update, looking forward to having the IPD available.

 

We are not opposed to a single key format in the specification and either seed or expanded key is OK.

 

> Caching expanded keys would not be allowed as there is minimal performance benefit to doing so

 

We do not agree with the comment that “caching” (or long-term storage) of expanded keys should not be allowed, as this should be left to the implementation.

Re-deriving the Decaps key from a seed for every operation (significantly) increases the attack surface for side-channel and fault attacks, and we do not believe this space is well enough understood to make this choice at this moment.

For example, the fixed weight rejection sampling was already the target of a timing attack in 2022. Although this concrete attack is not applicable here, we believe rejection sampling remains a possible weak spot for implementation security.

Protecting a static key (e.g., with a checksum) is generally simpler than one that is dynamically generated repeatedly, and the performance impact can be significant depending on the required countermeasures.

 

It is not clear to us what the benefit is of disallowing caching/storing expanded keys, whereas there are clear downsides for high-assurance implementations.

It would be helpful if NIST could clarify their position on caching.

 

Kind regards,

Joost (on behalf of NXP PQC team)

 

 

From: 'Robinson, Angela Y. (Fed)' via pqc-forum <pqc-...@list.nist.gov>

Sent: Monday, August 3, 2026 7:14 AM
To: pqc-forum <pqc-...@list.nist.gov>

Subject: [EXT] [pqc-forum] Upcoming FIPS 207 - Key format

 

Caution: This is an external email. Please take care when clicking links or opening attachments. When in doubt, report the message using the 'Report this email' button

--

[Sophie Schmieg]

Greatly appreciate the movement to only specify the seed as the exchange format. What an implementation does internally should continue to be left to the implementation with the whole "mathematically equivalent" framing we have used previously.

To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/DB9PR04MB11557F1B5F65696E5C48519DEFFD52%40DB9PR04MB11557.eurprd04.prod.outlook.com.

--

Sophie Schmieg | Information Security Engineer | ISE Crypto | ssch...@google.com

[Markku-Juhani O. Saarinen]

Hi,

First of all, for this, NIST would want to make sure that the samplers used in key generation can be implemented in a secure way.

The sampler in the latest reference public implementation (v 5.0.0) does not match the latest specification available to me ( 2025-08-22 ), so it is difficult to say what kind of secret key sampler NIST will propose in the IPD (if it is securely implementable without a severe performance handicap):

- XOF consumption: Table 1 specifies squeezing exactly |out| bytes. The v5.0.0 implementation rounds every request up to eight bytes and discards the excess. For the secret sampler's 3*w reservoirs, it discards 2, 4, and 7 bytes for HQC-1, HQC-3, and HQC-5, respectively. I had to follow the implementation, rather than the specification, in order to match the test vectors.

- Constant time: The reference sampler has seed-dependent loop counts, refills, and duplicate checks. Therefore, it is not constant time under the usual fixed-control-flow definition. The PDF uses a weaker qualification allowing leakage associated with rejected randomness. There are constant-time implementation techniques for this, but they have some overhead.

On "only format to be used is the seed" --  we will need to wrap keys, etc, and in some cases, we want to prohibit secret key export absolutely, so language used should be careful.

I think NIST should * allow * implementations to store secret keys in a secure, implementation-specific fashion, as long as the implementations also provide an FIPS interface for compliance testing ( not to repeat the mistake of the SP 800-208 discussion on secret keys, which severely handicapped implementations and delayed deployment by many years.)

Perhaps good to follow the old Doctor's maxim "First, do no harm"; the principle that an intervention should not create more harm than the condition it is intended to treat. So do not unnecessarily restrict implementation aspects that do not affect practical interoperability or compliance, such as secret key storage.

Cheers,

-markku

Dr. Markku-Juhani O. Saarinen <mj...@iki.fi>

--

[William Whyte]

Hi Angela,

I wanted to clarify the proposal by reference to FIPS 203.

In FIPS 203, section 3.3, the subsection "Destruction of intermediate values" says that implementations "shall ensure that intermediate data is destroyed as soon as it is no longer needed... only the designated output can be retained in memory after the algorithm terminates. All other data shall be destroyed prior to the algorithm terminating." It then lists two exceptions: 1) the seed generated in steps 1 and 2 of ML-KEM.KeyGen, which it says can be stored for later expansion using ML-KEM.KeyGen_internal; and 2) the matrix \hat{A} generated in K-PKE.KeyGen.

My understanding of the discussion of the "format" below (which is an unfortunate word to use because the word "format" doesn't appear anywhere in FIPS 203, except as part of "information") is that you're proposing to say that:

• After running HPC-KEM.KeyGen, only the seed and the public key are to be retained in memory
• When running HPC-KEM.Decaps, the "decryption key" input is the seed and the Decaps algorithm includes an internal call to HPC-KEM.KeyGen_internal to use the seed to regenerate the private key (which will then be destroyed prior to Decaps terminating).

Is that a correct statement of the proposal?

Are there other aspects of the proposal, for example for key formatting for import and export? I would assume not, because FIPS 203 doesn't address those topics either.

On the substance of the proposal, if I've got it right: I'm with most of the commenters so far in thinking this isn't necessary. I understand that the way to think about this proposal is that, if it's implemented, FIPS 140-certified cryptographic modules will have to delete the derived private key after every use. If that affected only federal government systems, that would be fine as a choice that NIST was making as appropriate for federal government systems (although I still wouldn't think it was necessary). However, FIPS 140 certification is a requirement in many settings outside the federal government, and it's reasonable to think that in some of those settings, storing the derived private key might be useful. (FIPS 140 is a victim of its own success here). Because of that, unless there's a compelling reason for NIST to require storing the seed only, my preference would be to allow the storage of the derived private key as well.

Cheers,

William

---

From: 'Sophie Schmieg' via pqc-forum <pqc-...@list.nist.gov>
Sent: Monday, August 3, 2026 5:08 PM
To: Joost Renes <joost...@nxp.com>
Cc: angela....@nist.gov <angela....@nist.gov>; pqc-...@list.nist.gov <pqc-...@list.nist.gov>
Subject: Re: [EXT] [pqc-forum] Upcoming FIPS 207 - Key format

WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.

To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CAEEbLAZLZbsR6w3ezcMydUMKxczAYs2-Yf5Xf-qHzOQbZhaeZg%40mail.gmail.com.

[Daniel Apon]

Hi FIPS 207 Team,

Allowing only the seed in the algorithm specification is a fine technical choice (many others are possible).

But more importantly, I think there is significant societal value in (and overwhelming evidence for) NIST restricting options; the way they are restricted in this case matter less than the fact they are restricted.
Leaving these choices open to the IETF or other bodies just will induce additional years of acrimonious debate prior to full adoption in practice.

Kind regards,
--Daniel

To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/DS0PR02MB106401A59421EC9410414C0ACF2D52%40DS0PR02MB10640.namprd02.prod.outlook.com.

[Demi Marie Obenour]

I don't think the expanded key format should ever appear in a standard, including FIPS 207. It's an implementation detail of a particular cryptographic module.

To use an analogy: Nobody sends individual AES round keys, but there are libraries (such as libsodium) that allow precomputing them as a performance optimization [1]. An expanded HQC secret key is just like a set of AES round keys in this respect.

[1]: https://libsodium.gitbook.io/doc/secret-key_cryptography/aead/aes-256-gcm/aes-gcm_with_precomputation

>> - After running HPC-KEM.KeyGen, only the seed and the public key are

>> to be retained in memory

>> - When running HPC-KEM.Decaps, the "decryption key" input is the seed

>> and the Decaps algorithm includes an internal call to
>> HPC-KEM.KeyGen_internal to use the seed to regenerate the private key
>> (which will then be destroyed prior to Decaps terminating).
>>
>>
>> Is that a correct statement of the proposal?
>>
>> Are there other aspects of the proposal, for example for key formatting
>> for import and export? I would assume not, because FIPS 203 doesn't address
>> those topics either.
>>
>> On the substance of the proposal, if I've got it right: I'm with most of
>> the commenters so far in thinking this isn't necessary. I understand that
>> the way to think about this proposal is that, if it's implemented, FIPS
>> 140-certified cryptographic modules will have to delete the derived private
>> key after every use. If that affected only federal government systems, that
>> would be fine as a choice that NIST was making as appropriate for federal
>> government systems (although I still wouldn't think it was necessary).
>> However, FIPS 140 certification is a requirement in many settings outside
>> the federal government, and it's reasonable to think that in some of those
>> settings, storing the derived private key might be useful. (FIPS 140 is a
>> victim of its own success here). Because of that, unless there's a
>> compelling reason for NIST to require storing the seed only, my preference
>> would be to allow the storage of the derived private key as well.
>>
>> Cheers,
>>
>> William
>>
>>
>>
>>

>> ------------------------------
>> *From:* 'Sophie Schmieg' via pqc-forum <pqc-...@list.nist.gov>
>> *Sent:* Monday, August 3, 2026 5:08 PM
>> *To:* Joost Renes <joost...@nxp.com>
>> *Cc:* angela....@nist.gov <angela....@nist.gov>;
>> pqc-...@list.nist.gov <pqc-...@list.nist.gov>
>> *Subject:* Re: [EXT] [pqc-forum] Upcoming FIPS 207 - Key format
>>
>> *WARNING:* This email originated from outside of Qualcomm. Please be wary

>> *From:* 'Robinson, Angela Y. (Fed)' via pqc-forum <pqc-...@list.nist.gov
>>>
>> *Sent:* Monday, August 3, 2026 7:14 AM
>> *To:* pqc-forum <pqc-...@list.nist.gov>
>> *Subject:* [EXT] [pqc-forum] Upcoming FIPS 207 - Key format
>>
>>
>>
>> *Caution:* This is an external email. Please take care when clicking

>> <https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/PH8PR09MB982319A0A2F2B7945C45594C8ED52%40PH8PR09MB9823.namprd09.prod.outlook.com?utm_medium=email&utm_source=footer>
>> .

>> --
>> You received this message because you are subscribed to the Google Groups
>> "pqc-forum" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to pqc-forum+...@list.nist.gov.
>> To view this discussion visit

>> https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/DB9PR04MB11557F1B5F65696E5C48519DEFFD52%40DB9PR04MB11557.eurprd04.prod.outlook.com
>> <https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/DB9PR04MB11557F1B5F65696E5C48519DEFFD52%40DB9PR04MB11557.eurprd04.prod.outlook.com?utm_medium=email&utm_source=footer>
>> .

>>
>>
>>
>> --
>>
>> Sophie Schmieg | Information Security Engineer | ISE Crypto |
>> ssch...@google.com
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "pqc-forum" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to pqc-forum+...@list.nist.gov.
>> To view this discussion visit
>> https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CAEEbLAZLZbsR6w3ezcMydUMKxczAYs2-Yf5Xf-qHzOQbZhaeZg%40mail.gmail.com

>> <https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CAEEbLAZLZbsR6w3ezcMydUMKxczAYs2-Yf5Xf-qHzOQbZhaeZg%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .

>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "pqc-forum" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to pqc-forum+...@list.nist.gov.
>> To view this discussion visit

>> https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/DS0PR02MB106401A59421EC9410414C0ACF2D52%40DS0PR02MB10640.namprd02.prod.outlook.com
>> <https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/DS0PR02MB106401A59421EC9410414C0ACF2D52%40DS0PR02MB10640.namprd02.prod.outlook.com?utm_medium=email&utm_source=footer>
>> .
>>
>


--
Sincerely,
Demi Marie Obenour (she/her/hers)

[si...@hoerder.net]

Hi all,

Practically I don’t see an issue with seed-only private key storage. But, on the theoretical side, I am somewhat worried that it will limit HQC’s ability to be a viable alternative to ML-KEM in *all* scenarios. What, for example, about applications with hard real-time constraints on existing hardware? Is there any guarantee that recomputing the key pair before using it will not violate the time constraints when ML-KEM with a fully expanded key pair does meet the time constraints? To be clear: I don’t know of such an application but I can’t rule out that such applications exist.

Furthermore, I want to second Markku-Juhani’s concerns. They are a bit off-topic for key storage formats but highly relevant for implementers in general. Standards that are inherently not constant time implementations are a major hassle in leakage testing. The fewer instances of inherently probabilistic timing a standard contains the better for testing. 

Finally, I would appreciate if NIST proactively communicates how they intend to check implementation requirements (e.g. “no caching” as this was mentioned here even though it’s probably badly phrased) during CAVP certification that the upcoming FIPS 207 may make. Untestable implementation requirements should be avoided as much as possible.

Best,

Simon

On 3 Aug 2026, at 23:49, Markku-Juhani O. Saarinen <mjos....@gmail.com> wrote:



To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CA%2BiU_qkdRe9A2wHC1OZDk0_y896cgFDMGEVodWcTTZgVuVBjvw%40mail.gmail.com.

[Kris Kwiatkowski]

Dear Angela,

I fully support standardizing the seed as the key format: it's compact, it allows checking keypairs, and expanding it during decaps is cheap since all the needed building blocks (XOF, samplers, multiplier) are already in any decaps implementation anyway (so no impact on binary size).

My only ask is that the standard should also allow implementations to use other private key formats internally. Two reasons:

1. Masked implementations. Masked decaps already goes through masked Keccak (G, J, re-deriving y from seedPKE.dk). With seed-only keys you add more masked Keccak calls, plus masked fixed-weight sampling of x and a masked multiplication for s. If the implementation is free to pick its own internal format, it can store the shared vectors directly, do the expensive derivation once at provisioning, and erase the seed.

2. Performance. If one key handles many decapsulations, re-deriving y, s and H(ekKEM) every time is pure overhead with no security benefit.

FIPS 203 already says: "a conforming implementation may replace the given set of steps with any mathematically equivalent set of steps." Similar principle could apply to keys: the seed is standardized and exchanged; internal representations that yield the same keypair are equally conformant.

Best regards,
Kris Kwiatkowski

[D. J. Bernstein]

https://nvlpubs.nist.gov/nistpubs/gcr/2018/NIST.GCR.18-017.pdf claims
that NIST's AES project saved $250 billion by 2017 by avoiding "costs
associated with the lack of network interoperability and
incompatibility" since "fragmentation would have led to higher
development, validation, testing, maintenance, and technical support
costs, as well as increased the complexity and vulnerability of
information systems".

Does this mean that NIST made a $500 billion mistake by standardizing
AES-128 _and_ AES-192 _and_ AES-256, three incompatible options, instead
of just AES-256? And then more damage with Keccak, Ascon, et al.?

The methodology used to come up with the $250 billion figure relies on
counterfactual guesswork without studying the actual costs of multiple
options in TLS etc., so I think the number should be taken with a grain
of salt. Option minimization shouldn't be treated as an overwhelming
consideration that automatically outweighs all other considerations. But
there's _some_ cost of multiple options.

The following example illustrates that the rationale for reducing
options applies even when multiple options are causing only test issues,
auditing issues, etc. rather than interoperability problems on the wire.
This example also illustrates that precomputed secret-key formats are
better than seeds from a testing perspective.

Here's the example: The ROCA disaster in certified devices (see
generally https://blog.cr.yp.to/20171105-infineon.html) stemmed from a
poor choice of an algorithm to generate secret primes for RSA, in an
environment where a diversity of such algorithms was tolerated and even
encouraged. This screwup had no effect on interoperability, but a
devastating effect on security. There are many easy ways this screwup
_could have_ been caught, such as

(1) testing that public keys pq take all 10 nonzero values mod 11 or

(2) testing that secret keys (p,q) take all 100 pairs of nonzero
values mod 11.

Test #2 is more powerful than test #1---it catches more screwups---but
if the secret key is replaced by a seed, with the key-generation work
moved inside subsequent secret-key operations (RSA signing, RSA dec,
etc.), then test #2 requires opening up the software instead of simply
inspecting secret-key outputs, so test #2 will be less likely to happen.

Sure, the devices broken by ROCA violated NIST's procedures to generate
primes; the devices were certified by Europeans, not by NIST; and there
were already general-purpose tests such as SUPERCOP's checksums that if
applied properly would have caught the problem. But all of these excuses
are missing the point. Standards end up implemented in libraries with a
wide range of testing practices. Testability, a goal recognized in NIST
standards for a wide range of technologies, considers the effectiveness
_and ease_ of tests, not just how effective the best possible tests are.
Saying ~"You didn't pay us for testing and certification so it's not our
fault that our standard led to your product failing" is irresponsible,
not how standards should be designed.

I'm baffled by some arguments that seem to be intentionally aiming for a
choose-your-own-adventure ecosystem where each piece of software is
using a seed format for everybody _and_ a precomputed format specific to
that software, with ad-hoc API extensions to include format conversions.
What's best for testability is a simpler API using a single format, a
standard precomputed format.

Again, testability is only one of many considerations. I'm _not_ saying
that it can't be outweighed by something else. But I haven't seen anyone
providing concrete examples of attack scenarios that would supposedly be
stopped by using seeds as the secret-key format, never mind laying out a
case that those risks outweigh the risks in the opposite direction.

I also haven't noticed anyone trying to make a quantitative argument
that expanding precomputed data beyond (e.g.) the 7317-byte keys for
hqc256round4 produces an important speedup---it sounds like NIST has
evaluated various expansion costs and decided that none of them matter,
although NIST didn't post details for verification---or that compressing
those to 32-byte seeds produces an important space savings. If there's
no actual problem with the round-4 format, why not stick to that?

I saw comments on HQC changing anyway because of IND-CCA2 issues; the
whole point is to achieve IND-CCA2, so this overrides compatibility. I
also saw a comment on part of sk being easy to remove; sure, makes
sense, and maybe doesn't compromise testability. But compressing down to
a seed definitely damages testability and needs serious justification.

As an example of handling this carefully: Classic McEliece internally
has a seed that allows some additional types of tests---and that will
allow compression _if this turns out to be important_. Meanwhile there's
no evidence that the compression is important. The spec mandates the
uncompressed sk format (e.g., 13932 bytes for mceliece6688128); the
official software uses just that format.

si...@hoerder.net writes:
> The fewer instances of inherently probabilistic timing a standard
> contains the better for testing.

I agree that rejection-sampling loops impose testing costs. For example,
in SUPERCOP, each rejection-sampling loop needs a crypto_declassify() to
get past TIMECOP, and then there's a burden on cryptanalysts to check
whether the declassified loop conditions are safe to reveal.

This particular testing work is of course not connected to the question
of whether a rejection-sampling loop is placed inside key generation or
inside dec. The loop needs declassification either way.

Recognizing the importance of testing does, however, show other ways
that it's good to move operations from dec to key generation, i.e., to
use a precomputed format for sk instead of a seed format for sk. See
above regarding the ROCA example. More broadly, to quote

https://web.archive.org/web/20260725191703/https://03283664099418252878.googlegroups.com/attach/aa2d2617e405/kem.pdf?part=0.0.1&view=1&vt=ANaJVrG49626Wd1S3wLbqmwUU0Hd2xTdcjcmLi4OarP59o48I8qFmbRKhwntZvswmoKCpELT2NT0cE0r0fj6qDlCqcJIC8yO2zT2gX85NONxfpwgJQY7zeI

on the same testability point:

> > Second, longer formats generally allow better tradeoffs between the ease
> > and reliability of tests. For example, if a private key includes a seed
> > and precomputed results, then a self-contained test of that bundle can
> > carry out the precomputation again. As another example, if an RSA
> > private key includes not just the secret primes p and q but also some
> > inverses modulo p − 1 and q − 1, then one can use multiplication to
> > check the inverses. As a post-quantum example, see
> > https://classic.mceliece.org/mceliece-impl-20221023. pdf#subsection.6.3.
> > Such checks can easily catch bugs in procedures for handling the
> > components of private keys.
> >
> > For comparison, a self-contained test of a seed is impossible. A
> > self-contained test of precomputed data is less effective than checking
> > a full private-key bundle. Multiple-item tests require the test
> > framework to support a more complicated data flow, and still can’t catch
> > mix-and-match bugs in applications.

The specific comment on "mix-and-match bugs" is referring to the first
software-security argument in the document, which is as follows:

> > First, storing private keys as seeds creates a speed incentive for
> > implementors to change the dec API to incorporate extra inputs, namely
> > the precomputed data that would normally have been stored in private
> > keys. This provides an opportunity for an application bug to incorrectly
> > mix and match seeds with extra inputs—which can easily damage security.
> >
> > As an ECC example, having such an extra input for Ed25519 is exactly
> > what leads libraries to be listed in
> > https://github.com/MystenLabs/ed25519-unsafe-libs. Ed25519 libraries
> > that instead use longer formats (for example, https://lib25519.cr.yp.to,
> > or any of the other Ed25519 libraries following the SUPERCOP API) do not
> > have this issue: they allow a simpler, more robust API where all
> > necessary information is simply bundled into the private key.

NIST seems to be missing these risks and conflating the following five
options for what the standard will specify:

(1) within the conventional KEM API, having dec's sk input be a
32-byte seed;

(2) within the conventional KEM API, having dec's sk input be a
(32+pkbytes)-byte seed-plus-public-key, with dec not checking
the key;

(3) deviating from the conventional KEM API to have dec take a
32-byte seed as sk input _and_ a public key as a separate input,
again with dec not checking the key;

(4) within the conventional KEM API, having dec's sk input be a
(32+pkbytes)-byte seed-plus-public-key, but now with dec
checking the key;

(5) deviating from the conventional KEM API to have dec take a
32-byte seed as sk input and a public key as a separate input,
with dec checking the key.

NIST's "the only format to be used is the seed" sounds like #1, but
NIST's "storing the standard encoding of the public key in addition to
the seed when doing decaps" sounds like either #2 or #3. NIST's speed
comment seems to be excluding #4 and #5, but it's hard to be sure about
this given, again, that NIST didn't post details of its speed analysis.

#1 encourages implementors to switch to #3. #3 is exactly where
mix-and-match bugs can appear. #2 is an example of the right direction,
including precomputed data in sk, but I don't see an analysis from NIST
saying why this particular choice is supposed to be the best, nor do I
see an explanation from NIST of whether it's acting on the basis of the
(vague) claims of security benefits of seeds---claims that seem unlikely
to apply equally to #1, #2, #3, #4, and #5, never mind the question of
whether the claims have any substantiation within their supposed scope.

The way that NIST has been handling these decisions reminds me of

https://www.edwardtufte.com/notebook/powerpoint-does-rocket-science-and-better-techniques-for-technical-reports/

and in particular the following quote from the Columbia Accident
Investigation Board: "The Board views the endemic use of PowerPoint
briefing slides instead of technical papers as an illustration of the
problematic methods of technical communication at NASA."

---D. J. Bernstein

[Thom Wiggers]

Dear Angela and the NIST team,

I would like to echo Bas’ sentiment: caching intermediate values is an implementation decision in my opinion; however, a clear signal that the data exchange format is seed-only will be greatly helpful for interoperability (which, after all, is why we do standards, right?) and avoid the nightmare situation that ML-KEM/ML-DSA ended up with

Cheers,

Thom

To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CAMjbhoULOsAHDZiAeMnKXv2DxNCYcCCGFfHy2tJN1NFacpQiAg%40mail.gmail.com.

[Kampanakis, Panos]

+1.

 

As others have suggested, it should not matter if a key is in seed or expanded format in memory within the FIPS boundary. Rederiving the expanded version every time is wasteful.

 

From: pqc-...@list.nist.gov <pqc-...@list.nist.gov> On Behalf Of Kris Kwiatkowski
Sent: Tuesday, August 4, 2026 6:42 AM
To: pqc-forum <pqc-...@list.nist.gov>
Cc: Robinson, Angela Y. (Fed) <angela....@nist.gov>
Subject: [EXTERNAL] [pqc-forum] Re: Upcoming FIPS 207 - Key format

 

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.

--

You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.

To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/ceb0b97d-f013-4f38-8b84-02932e30abc6n%40list.nist.gov.

[Scott Fluhrer (sfluhrer)]

I believe that, in general, NIST shouldn't make these implementation type decisions.  NIST knows less about a specific implementation than the actual implementors - what NIST believes is a bad trade-off might not be for some.

Of course, this assumes that there are no security or interoperability issues involved with those decisions - of course, those are valid things for NIST to consider.

---

From: 'Kampanakis, Panos' via pqc-forum <pqc-...@list.nist.gov>
Sent: Tuesday, August 4, 2026 9:47 AM
To: Robinson, Angela Y. (Fed) <angela....@nist.gov>
Cc: pqc-forum <pqc-...@list.nist.gov>
Subject: RE: [pqc-forum] Re: Upcoming FIPS 207 - Key format

To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/BYAPR18MB2648768B503F3133CC9813EEABD42%40BYAPR18MB2648.namprd18.prod.outlook.com.

[Tony Arcieri]

I am a big fan of specifying just seeds for HQC-KEM.

Specifying both seeds and expanded key formats for ML-KEM led to some confusion when specifying things like the PKCS#8 private key format, which for ML-KEM is significantly more complex than it needs to be, incorporating variants for seeds, expanded keys, and both. Various implementations have chosen what parts they will support: some only support seeds, some need to support keys that weren't originally generated from seeds. This has lead to a bit of an interoperability mess which is unfortunate for a new standard.

--

I'm not sure why the standard would be opinionated regarding purely opaque caching, especially if the rationale is performance-oriented.

FWIW the RustCrypto implementation of HQC-KEM expands from a seed to a type which uses the expanded key in-memory. Is this suggesting that if we-as-a-library ever hand the caller back a decapsulation key value which internally uses the expanded format in-memory, even if it can't be serialized by the caller, would we be guilty of violating this "caching" directive? Whether or not the expanded key is discarded after performing a single decapsulation is ultimately up to the caller.

We can change our implementation to always store and expand from the seed but that's a change I likely wouldn't make except if I needed to do so for standards compliance purposes. It would likely make our code a bit messier as in such a case we'd probably just duplicate our existing decapsulation key type but make it an internal implementation detail, then add yet another decapsulation key type for the public API which always expands from the seed.

[D. J. Bernstein]

'Scott Fluhrer (sfluhrer)' via pqc-forum writes:
> I believe that, in general, NIST shouldn't make these implementation
> type decisions.

Sorry, can you clarify what you mean by "implementation type decisions"
here?

If you're objecting on scope grounds to NIST saying "Caching expanded

keys would not be allowed as there is minimal performance benefit to
doing so (compared to just storing the standard encoding of the public

key in addition to the seed when doing decaps)", are you also objecting
on scope grounds to, e.g., NIST in FIPS 203 saying "Implementations of
ML-KEM shall not use floating-point arithmetic, as rounding errors in
floating-point operations may lead to incorrect results in some cases"?
Is that not an "implementation type decision"?

As far as I know, NIST never provided any evidence for their claim that
floating-point software for ML-KEM is more likely to be wrong than
integer software for ML-KEM, nor did they consider the possibility of
platforms where floating-point arithmetic would avoid timing leaks of
integer arithmetic while also being faster. And yet they constrained
this detail of how ML-KEM computations are done, a detail that seems
much more obviously internal than secret-key formats. Cryptographic
specs often contain examples of secret keys as test cases, and sometimes
include worked examples of intermediate results of computations beyond
the designated inputs and outputs, but it's rare to see something at the
level of "put numbers in _this_ type of CPU register, not _that_ type".
I'm not sure how a scope constraint would allow that without also
allowing a caching prohibition.

---D. J. Bernstein

[Richard Kettlewell]

On 03/08/2026 13:13, 'Robinson, Angela Y. (Fed)' via pqc-forum wrote:
> Dear All,
>
> NIST is preparing to release the FIPS 207 (HQC-KEM) Initial Public Draft
> soon and wanted to announce our current plan regarding the key format.
> NIST is leaning toward specifying that the only format to be used is the

> seed.  Caching expanded keys would not be allowed as there is minimal

> performance benefit to doing so (compared to just storing the standard

> encoding of the public key in addition to the seed when doing decaps) .
> This is a different approach from FIPS 203 which allows for both the
> seed and the expanded key formats.   Our current inclination is a result
> of the feedback NIST received after the publication of FIPS 203 that one
> key format was preferable to two.
>
> NIST would like to hear thoughts on the matter, especially if there are
> any opposed to the standardization of seeds as the only permissible key
> format in FIPS 207.

The multiple private key formats that have emerged for ML-DSA and ML-KEM
have added complexity to our implementation and to associated
specifications that we need to implement (e.g. RFC9935). Committing to a
single representation of private keys will save specialist effort.

I would also ask that key formats be explicitly defined byte strings in
all future specifications. ML-DSA and ML-KEM both satisfy this request
(once you've decided whether to use seeds or expanded keys) but SLH-DSA
does not since the keys are tuples of byte strings[1].

The reason for this request is to ensure a key can have the same
representation at rest inside an HSM, in a PKCS#11 attribute, in an
RFC5958 OneAsymmetricKey, and in other APIs.

[1] That said: since each component of an SLH-DSA key has a fixed
length, there's a natural interpretation as a single byte string formed
by concatenating the components, e.g.
https://www.rfc-editor.org/rfc/rfc9909.html#name-private-key-format
which has also been adopted (implicitly as far as I can see) by PKCS#11,
so this isn't much of a problem in practice.

ttfn/rjk

[Scott Fluhrer (sfluhrer)]

Actually, I believe that for SLH-DSA, FIPS 205 does define the public key and private key formats; see Figure 15 and 16 from FIPS 205 (bottom of page 33)

---

From: pqc-...@list.nist.gov <pqc-...@list.nist.gov> on behalf of Richard Kettlewell <r...@terraraq.uk>
Sent: Wednesday, August 5, 2026 10:43 AM
To: pqc-...@list.nist.gov <pqc-...@list.nist.gov>
Subject: Re: [pqc-forum] Upcoming FIPS 207 - Key format

I would also ask that key formats be explicitly defined byte strings in

all future specifications. ... but SLH-DSA

does not since the keys are tuples of byte strings[1].

[1] That said: since each component of an SLH-DSA key has a fixed
length, there's a natural interpretation as a single byte string formed
by concatenating the components, e.g.
https://www.rfc-editor.org/rfc/rfc9909.html#name-private-key-format
which has also been adopted (implicitly as far as I can see) by PKCS#11,
so this isn't much of a problem in practice.

ttfn/rjk

--
You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+...@list.nist.gov.

To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/3e0a1597-f0e9-4b94-8efc-7effc2508f88%40terraraq.uk.

[D. J. Bernstein]

Thom Wiggers writes:
> I would like to echo Bas’ sentiment: caching intermediate values is an
> implementation decision in my opinion; however, a clear signal that
> the data exchange format is seed-only will be greatly helpful for
> interoperability (which, after all, is why we do standards, right?)
> and avoid the nightmare situation that ML-KEM/ML-DSA ended up with

Wait, is NIST's question about a "data exchange format"?

I assumed that NIST was talking about what the input should be to the
dec algorithm in the spec (aside from a ciphertext). This would end up
turning into a format commonly used in HQC implementations (but not the
only format if it's chosen poorly---see below) and in HQC test vectors.

If "the only format to be used" is instead talking about all storage
and usage of sk, does it prohibit an application from applying an
error-correcting code to sk to protect against faults, either in
software or via ECC RAM? What about randomization to protect against
side-channel attacks? What about further encodings in GPG, SSH, etc.?

If the format really is "seed-only", is an application not allowed to
store (seed,pk) as sk? Does it have to choose between taking pk as a
separate input---risking mismatches---or incurring the cost of
recomputing pk from sk on each dec?

If the decision is instead that seeds are required but that other
formats are allowed, won't a bunch of implementations decide to turn
the simple keygen/enc/dec API into keygen/expand/enc/decusingexpansion,
with a mess of ad-hoc choices of poorly tested expansion details and
poor interchangeability between implementations? How exactly is this
supposed to be better than specifying a single longer sk format that's
output by keygen and input by dec, skipping the distraction of seeds as
sk? (See also my separate comments on software-security advantages of
longer formats.)

Are any of the people claiming security advantages of seeds via
"binding" able to explain which of these situations supposedly provides
"binding"? For example, does NIST's proposed "storing the standard
encoding of the public key in addition to the seed", apparently with
consistency not checked in dec, provide "binding"? What's a concrete
example of an attack scenario where this is supposed to matter?

Regarding the "nightmare situation" for ML-KEM: The ML-KEM ecosystem was
certainly shooting itself in the foot---or should I say shooting itself
in the secret key? ouch!---by allowing multiple sk formats. But this by
itself doesn't say anything about which format is best.

The original ML-KEM sk format was a reasonable choice: there's
negligible space savings from something smaller, and negligible time
savings from something larger. There was then a self-inflicted wound
from a push for seeds on claimed security grounds that nobody seems able
to substantiate. It seems that HQC is being steered into an even worse
situation where the ecosystem will end up with even more formats, while
NIST takes even less responsibility for the damage.

---D. J. Bernstein

[John Mattsson]

Richard Kettlewell wrote:

>I would also ask that key formats be explicitly defined byte strings in all future specifications

Yes please.

Richard Kettlewell wrote:

>but SLH-DSA does not since the keys are tuples of byte strings[1].

Scott Fluhrer wrote:

>Actually, I believe that for SLH-DSA, FIPS 205 does define the public key and private key formats; see Figure 15 and 16 from FIPS 205 (bottom of page 33)

Maybe SP 800-230 could clarify that this are the byte string public key and private key formats.

Cheers,

John Preuß Mattsson

[Richard Kettlewell]

On 06/08/2026 05:58, 'John Mattsson' via pqc-forum wrote:
> Richard Kettlewell wrote:
> >I would also ask that key formats be explicitly defined byte
> strings in all future specifications
>
> Yes please.
>
> Richard Kettlewell wrote:
> >but SLH-DSA does not since the keys are tuples of byte strings[1].
> Scott Fluhrer wrote:
>>Actually, I believe that for SLH-DSA, FIPS 205 does define the public key and private key formats; see Figure 15 and 16 from FIPS 205 (bottom of page 33)

That's a pretty reasonable interpretation, but it doesn't quite meet my
request for the description to be explicit, since there's no statement
(that I can see) that the box notation in FIPS-205 indicates concatenation.

> Maybe SP 800-230 could clarify that this are the byte string public key
> and private key formats.

That would be helpful.

ttfn/rjk

[Thom Wiggers]

Hello Dan,

Op 5 aug 2026, om 22:17 heeft D. J. Bernstein <d...@cr.yp.to> het volgende geschreven:

Wait, is NIST's question about a "data exchange format”?

I will only clarify what I mean with “data exchange format” for the sake of others and not engage with the remaining meandering arguments made in your email.

In my view, an extremely large part of the “seed” vs “expanded” discussion was about there existing “legacy” HSM and FIPS-queued implementations of ML-DSA/ML-KEM that only generated the “expanded” format while there were strong technical arguments for having “seed” as a key format in other implementations. These keys needed to be transportable to later generations of hardware in the future. Since the seeds were thrown away, these keys would be left behind in those old HSMs if we had chosen to define the “data exchange formats”  (i.e., the relevant IETF LAMPS specs) to allow representing seeds only. “expanded” only would be annoying because you can’t go back to seeds for those who needed that.

We ended up with a situation where for the sake of preserving the technical debt incurred by these pre-standards implementations of the PQC algorithms, we now forever carry significant technical debt in the importing of these secret keys, as there is now more involved ASN.1 code. 

So in summary, this is in many ways exactly about how to move bits around.

Regards,

Thom

[D. J. Bernstein]

Thom Wiggers writes:
> there were strong technical arguments for having “seed” as a key format

Namely?

I keep hearing insinuations of security benefits compared to a longer sk
format. What's an example of an attack scenario that would be stopped by
using a 64-byte sk for ML-KEM? Or by a 32-byte seed as sk? Or, more to
the point, by NIST having "the standard encoding of the public key in
addition to the seed" as HQC dec input?

> > Wait, is NIST's question about a "data exchange format”?
> I will only clarify what I mean with “data exchange format”

I don't see how your example (the format used to communicate an sk from
an HSM to another HSM) clarifies any ambiguities in that concept, nor do
I see how it answers any of my questions about what NIST meant by "the
only format to be used is the seed", nor do I see how it would be
possible to reach clarity if NIST doesn't clarify.

> “expanded” only would be annoying because you can’t go back to seeds
> for those who needed that.

This specific argument (1) is preconditioned on the idea that someone
actually needs seed format in the first place and (2) is in any case not
an argument against an expanded format that starts with a seed (such as
an sk that includes "the standard encoding of the public key").

> We ended up with a situation where for the sake of preserving the
> technical debt incurred by these pre-standards implementations of the
> PQC algorithms, we now forever carry significant technical debt in the
> importing of these secret keys, as there is now more involved ASN.1 code.

Contrary to what readers might think from the phrase "pre-standards
implementations" and the accompanying pejorative wording ("legacy" and
"technical debt" and so on): An implementor who simply implements the
main algorithms in FIPS 203 will _not_ use seed as secret-key format.

Specifically, FIPS 203 specifies "the three main algorithms of the
ML-KEM scheme" as

* "ML-KEM.KeyGen()", which outputs public key "ek" and private key
"dk", the latter having "768k+96" bytes;

* "ML-KEM.Encaps(ek)", which outputs a shared secret and ciphertext;
and

* "ML-KEM.Decaps(dk,c)", which outputs a shared secret.

The "dk" (i.e., sk) format there is not 32 or 64 bytes.

An implementor who looks for further options will find FIPS 203 saying
that an internal 64-byte format "can be stored for later expansion" into
dk, but an implementor who cares about simplicity of the API won't do
that by default and won't notice anything in FIPS 203 indicating a
reason to do it. (Similar comments apply to FIPS 204.)

However, the fact that NIST _allowed_ the 64-byte format then opened up
a path for downstream to _use_ the 64-byte format, leading to the
current mess of multiple formats in current ML-KEM APIs. The obvious
ways to avoid multiple formats would instead have been

(1) sticking entirely to the original sk format _or_
(2) converting entirely to the 64-byte format.

A rational decision of what to do wouldn't be based on the number of TV
ads portraying #1 as archaic vs. the number of TV ads portraying #2 as a
cargo cult; it would be based on a cost-benefit analysis of clearly
defined proposals.

---D. J. Bernstein