Is it FIPS-compliant to use private key seed for ML-DSA / ML-KEM?

[Mike Ounsworth]

Hi NIST pqc-forum! (CC IETF PQUIP)

 

Context: within the IETF there’s a push to standardize seed-based private key storage for ML-DSA and ML-KEM (aka in PKCS#12 files). There are a number of great advantages of seed-based private keys, including bandwidth, resistance to publickey-privatekey mismatch attacks, and the observation that ML-DSA + Ed25519 and ML-KEM + X25519 hybrids can efficiently derive both halves from the same 32-byte seed is brilliant [1]

 

But it just came to my attention that private key seed might be forbidden by FIPS 203 / 204. Specifically, re-expanding the key from seed requires access to the KeyGen_internal function, and both 203 and 204 have similar wording in their introductions to their “Internal Functions” sections:

 

“Other than for testing purposes, the interfaces for key generation and signature generation specified in this section should not be made available to applications, as any random values required for key generation and signature generation shall be generated by the cryptographic module.”

 

Which seems like it would forbid an application in FIPS-mode from importing / exporting a private key as a seed.

 

 

However, there is also language:

 

“Two particular cases in which implementations may refrain from destroying intermediate data are:

1. The seed 𝜉 generated in step 1 of ML-DSA.KeyGen can be stored for the purpose of later expansion using ML-DSA.KeyGen_internal. As the seed can be used to compute the private key, it is sensitive

data and shall be treated with the same safeguards as a private key”

 

Which seems to imply that it’s perfectly ok for an application to access ML-DSA.KeyGen_internal and to store the private key as a seed. But this language seems to be in conflict with the language above.

 

 

So which is it? Is it FIPS-compliant to import / export private keys as seeds in, for example, PKCS#12 files?

 

 

PS – sorry if this has been asked and answered already, I’m suffering from hyper-email-itis between this and all the IETF email lists.

 

[1]: https://datatracker.ietf.org/doc/draft-connolly-cfrg-xwing-kem/

---
Mike Ounsworth
Software Security Architect, Entrust

 

[Orie Steele]

Hi Mike,

This topic was discussed here: 

https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/2EWXvBaE-Yw/m/7mdhdEqvAwAJ

There is also this interesting draft related to key generation which seems relevant to this discussion:

https://datatracker.ietf.org/doc/draft-bradleylundberg-cfrg-arkg/

Expanding seeds for use with ML-DSA / BLS seems less critical than ensuring that ML-KEM hardware support and export features are ready to go asap.

Given the threat of "harvest now / decrypt later attacks", it's concerning that we might see further delay of ML-KEM rollout related to support for use of private keys from seeds with approved key derivation functions.

OS

--
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/CH0PR11MB573944D1440B5F75DB7260E29F4B2%40CH0PR11MB5739.namprd11.prod.outlook.com.

--

ORIE STEELE
Chief Technology Officer
www.transmute.industries

[Gorjan Alagic]

Hi Mike,

For FIPS 203, we should distinguish between two things here:

1.) [Allowed] Generating a 64-byte seed (d, z) using a DRBG, storing (d, z) instead of the decapsulation key, and then re-expanding later using ML-KEM.KeyGen_internal(d, z). This is explicitly allowed by FIPS 203, in the text just above the definition of KeyGen_internal (“The key generation function in this section may also be used to re-expand a key from a seed…”). This is also discussed in Section 3.3 as an exception to the “destroy intermediate values” rule. There should be no ambiguity here, so if this is still unclear, please let me know.
2.) [Not presently allowed] Generating the 64-byte seed (d,z) from a 32-byte seed s using (e.g.) a KDF, and then storing s instead of the decapsulation key. As discussed in the thread linked by Orie, this is at present not allowed, but we are looking at allowing it via a change to SP800-133. Feedback here is very welcome, but it’s probably best if it goes in that thread (https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/2EWXvBaE-Yw/m/7mdhdEqvAwAJ).

Best,
Gorjan

To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+unsubscribe@list.nist.gov.

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

[Deirdre Connolly]

I think part of the confusion is FIPS 203 says storing the (d, z) seed is allowed and it can be expanded via calling `ML-KEM.KeyGen_internal()`, but then elsewhere in the document it says "the [internal] interfaces specified in this section should not be made available to applications other than for testing purposes". That is a 'should not', vs a "shall not", so we can do it, it's just a bit confusing/dissonant

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/CH0PR11MB573944D1440B5F75DB7260E29F4B2%40CH0PR11MB5739.namprd11.prod.outlook.com.

--

ORIE STEELE
Chief Technology Officer
www.transmute.industries

--

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/5b603caa-849b-4c65-bed4-aae1aa25670cn%40list.nist.gov.

[John Mattsson]

FIPS 203 also says that:

”For every computational procedure that is specified in this standard, a conforming implementation may replace the given set of steps with any mathematically equivalent set of steps. In other words, different procedures that produce the correct output for every input are permitted.”

I interpret APIs as mathematical steps in the computation process. For example, a single call to multiply() could be replaced by multiple calls to add(). My view would be FIPS 203 can implemented with different APIs and still be compliant with the FIPS 203 specification. That is different from FIPS-validation, which might require a specific API for practical purposes.

Cheers,
John

 

--
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/5b603caa-849b-4c65-bed4-aae1aa25670cn%40list.nist.gov.

--

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/CAFR824z1Cuah3mG55VF2n7H7E0DLU4F%3Dwyk-R5soStqC9PMpwQ%40mail.gmail.com.

[Mike Ounsworth]

++ Deirdre.

 

(sorry for repeating myself from my other email).

 

It seems clear to me that FIPS 203 allows a crypto module to *internally* store the (properly-DRBG’d) 64 byte seed and call ML-KEM.KeyGen_internal() at a later time. What is not clear to me is if FIPS 203 allows you to import a 64 byte seed from outside the cryptographic module (ex.: via  PKCS#12 file), because then the module has no way to prove that the seed was generated with an approved DRBG. Gorjan’s statement that this is allowed seems in direct conflict with the language discouraging KeyGen_internal() from being exposed to applications.

 

 

Also, I would like this same question specifically answered about ML-DSA (FIPS 204) where Section 6 does not contain that sentence about re-expanding a key from a seed. Are private key seeds allowed for ML-KEM but not for ML-DSA?

 

---

Mike Ounsworth

 

From: Deirdre Connolly <durumcr...@gmail.com>

Sent: Wednesday, October 30, 2024 1:21 PM
To: Gorjan Alagic <gorjan...@nist.gov>

Cc: pqc-forum <pqc-...@list.nist.gov>; Orie Steele <or...@transmute.industries>; p...@ietf.org <p...@ietf.org>; Mike Ounsworth <Mike.Ou...@entrust.com>
Subject: [EXTERNAL] Re: [pqc-forum] Is it FIPS-compliant to use private key seed for ML-DSA / ML-KEM?

 

I think part of the confusion is FIPS 203 says storing the (d, z) seed is allowed and it can be expanded via calling `ML-KEM. KeyGen_internal()`, but then elsewhere in the document it says "the [internal] interfaces specified in this section

[Quynh Dang]

Hi Deirdre,

There are only 2 uses of Algorithm 16 ML-KEM.KeyGen_internal(𝑑,𝑧) where it can be called directly.

1) ACVP tests this function.

2) It is used and is allowed to derive a key pair from (d, z).

But I agree that the word “should” is not a best word.

Regards,
Quynh.

PS. I apologize if you received this message a second time. My Outlook acted weird when someone sent a signed email to me and I replied to it.  

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

[Madjid Nakhjiri]

This would be a critical design consideration for HW design as a private key of around 5KB is very costly to put in an OTP or other type of private memory within crypto module, so we have been counting on the ability to generate and store the seed once and then generate the private key within the crypto module. This comes with a performance cost but the alternative would be storing the private key off the module in some encrypted form which brings another problems ..

thanks,

Madjid

--

[Gorjan Alagic]

Hi all,

For both FIPS 203 and FIPS 204, a KeyGen seed is considered an acceptable alternative format for the private (i.e., decapsulation or signing) key. In particular, generating the seed in one cryptographic module and then importing it into another cryptographic module is allowed.

Some additional comments:
- The seed still must be generated by a cryptographic module using an appropriate NIST-approved DRBG. The cryptographic module that performs this generation need not be an ML-KEM/ML-DSA-capable module.
- I agree that there's text in 203 that is confusing on this point. I'm sorry about that. But: using seeds as above is definitely ok.
- I agree that having a seed import function does not seem to require exposing KeyGen_internal to applications. (And that, ultimately, not exposing KeyGen_internal is only a "should.")
- I realize that there are now also a number of posts about this topic in the other pqc-forum thread (https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/2EWXvBaE-Yw). However, that thread was started to discuss the potential 32-byte seed format option for ML-KEM, and mixing these two topics seems to be generating some confusion over there.

Best,
Gorjan

To unsubscribe from this group and stop receiving emails from it, send an email to pqc-forum+unsubscribe@list.nist.gov.

[Mike Ounsworth]

Thank you Gorjan for the very clear statement. This fully resolves the issue for me!

---

Mike Ounsworth

---

From: 'Gorjan Alagic' via pqc-forum <pqc-...@list.nist.gov>
Sent: Friday, November 1, 2024 4:10:55 PM
To: pqc-forum <pqc-...@list.nist.gov>
Cc: Madjid Nakhjiri <madjidn...@gmail.com>; pqc-forum <pqc-...@list.nist.gov>; p...@ietf.org <p...@ietf.org>; Mike Ounsworth <Mike.Ou...@entrust.com>

Subject: [EXTERNAL] Re: [pqc-forum] Is it FIPS-compliant to use private key seed for ML-DSA / ML-KEM?

 

Hi all, For both FIPS 203 and FIPS 204, a KeyGen seed is considered an acceptable alternative format for the private (i. e. , decapsulation or signing) key. In particular, generating the seed in one cryptographic module and then importing it into

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/bf813ede-5b82-4103-82dd-d89f0d761812n%40list.nist.gov.

Any email and files/attachments transmitted with it are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.