Re: [pqc-forum] Re: ML-KEM: usage of seed for key pair generation

[Blumenthal, Uri - 0553 - MITLL]

Gorjan,

 

Please clarify: is NIST objecting to the seed size, considering 32 byte too short, or is NIST objecting to “official” use of seed in ML-KEM?

 

Given how ML-KEM key-pairs are generated, I see the change to allow (only) a seed (of, say, 40 bytes) as a really small task.

If you think otherwise – please explain what problems you find with this approach.

 

P.S. My previous question on this subject was ignored – please follow the process and respond.

--

V/R,

Uri

 

There are two ways to design a system. One is to make it so simple there are obviously no deficiencies.

The other is to make it so complex there are no obvious deficiencies.

                                                                                                                                        C. A. R. Hoare

 

I was a shepherd to fools

Causelessly bold or afraid.

They would not abide by my rules.

Yet they escaped. For I stayed.

                                    R. Kipling “Epitaphs of the War. Convoy Escort”

 

 

From: 'Alagic, Gorjan (Assoc)' via pqc-forum <pqc-...@list.nist.gov>
Date: Tuesday, September 17, 2024 at 20:45
To: Phillip Hallam-Baker <ph...@hallambaker.com>, Tony Arcieri <bas...@gmail.com>
Cc: pqc-forum <pqc-...@list.nist.gov>
Subject: [EXT] RE: [pqc-forum] Re: ML-KEM: usage of seed for key pair generation

Using only a 32-byte seed for ML-KEM is not allowed by FIPS 203, and we have no plans to allow it. It’s true that having such an option might be advantageous for some applications. However, we do not see this as a sufficient reason to change

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside the Laboratory.

 

ZjQcmQRYFpfptBannerEnd

Using only a 32-byte seed for ML-KEM is not allowed by FIPS 203, and we have no plans to allow it. It’s true that having such an option might be advantageous for some applications. However, we do not see this as a sufficient reason to change FIPS 203, either directly or indirectly. Making a change at this stage is no small task, and could have unintended consequences. – Gorjan (for NIST PQC team).

 

From: pqc-...@list.nist.gov <pqc-...@list.nist.gov> On Behalf Of Phillip Hallam-Baker
Sent: Friday, September 13, 2024 3:25 PM
To: Tony Arcieri <bas...@gmail.com>
Cc: pqc-forum <pqc-...@list.nist.gov>
Subject: Re: [pqc-forum] Re: ML-KEM: usage of seed for key pair generation

 

I think it is important to have the domain separation as specified later in the thread. The way I would do this is to bind the OID of the algorithm ID into the hash which is consistent with approach elsewhere in ML-DSA.

 

So:

 

Seed = 32 bytes

d, k = SHAKE-256 ( oid + seed, 512 bits);

 

I believe that as a general matter, no cryptographic operation should use the output of any RNG without pre-processing it through a digest precisely to prevent a repeat of the DUAL-ECC RNG situation.

 

 

 

On Fri, Sep 13, 2024 at 12:12 PM Tony Arcieri <bas...@gmail.com> wrote:

I now see this was already proposed using SHAKE-256 to perform the expansion: https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/5CT4NC_6zRI/m/lpifFrpWAwAJ

 

On Tue, Sep 10, 2024 at 7:27 AM Tony Arcieri <bas...@gmail.com> wrote:

On Fri, Sep 6, 2024 at 2:10 PM Stephan Mueller <smue...@chronox.de> wrote:

But my concern is slightly different, considering
that FIPS 203 explicitly says the seed must come from an RBG and not from a
plain KDF which provides seed data for different ML-KEM keys.

My concern is more along the lines what FIPS 203 says: a fresh random number
is to be generated from an RBG each time a new key pair is created. However,
instead of wanting to store the key pair or the private key, storing the seed
is allowed. All I am asking is whether instead of storing 64 bytes from an
RBG, I can store 32 bytes from an RBG and expand the 32 bytes to 64 bytes
using a KDF to regenerate the one given key pair the seed applies to.

 

Can NIST offer any guidance here? Is there any approved construction for expanding a 32-byte "short seed" into 64-bytes? Particularly in a way where the 32-byte seed can be persisted and expanded as needed? Would this be against the usage requirements of a DRBG due to the need to persist the "short seed", and if so, what would be an approved construction to use?

 

--

Tony Arcieri

 

--

Tony Arcieri

--
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 on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CAHOTMV%2B%3DPuuj%3DH4FV_Z6dSSU%2Bs6Uews7z8ZbAi1cywjEnEhhoQ%40mail.gmail.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 on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CAMm%2BLwgh%2Bq9%3DtvvL8h3De25D0NTA%2B2Tqcj5benLZ_B%3D5ykR%3D4Q%40mail.gmail.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 on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/DM6PR09MB4726A89BA10428F937C4EF169A622%40DM6PR09MB4726.namprd09.prod.outlook.com.

[Alagic, Gorjan (Assoc)]

Hi Uri,

Sorry for the delay in responding. We had some internal discussions that I wanted to finish first.

The concern is not about the specific idea of using a 32-byte seed for ML-KEM.KeyGen. It is instead a general concern about making any changes to FIPS 203 at this stage.

 

Can you say more about the specific use-case you are interested in?

Best,

Gorjan

[Filippo Valsorda]

2024-10-02 13:44 GMT+02:00 'Alagic, Gorjan (Assoc)' via pqc-forum <pqc-...@list.nist.gov>:

Hi Uri,

Sorry for the delay in responding. We had some internal discussions that I wanted to finish first.

The concern is not about the specific idea of using a 32-byte seed for ML-KEM.KeyGen. It is instead a general concern about making any changes to FIPS 203 at this stage.

 

Can you say more about the specific use-case you are interested in?

Hi Gorjan,

Not speaking for Uri, but I had asked to clarify if you interpret FIPS 203 to prohibit the use of SP 800-108 KDFs to derive seeds, despite SP 800-133 and FIPS 140-3 IG D.H mentioning "asymmetric seeds". I would argue that's a matter of interpretation, not of changing FIPS 203.

My use case is deriving decapsulation keys for hybrids from the same source key material in a rigid, well-specified, domain separated, testable way, instead of storing them separately.

Thank you,

Filippo

To view this discussion on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/DM6PR09MB4726C996C60A5DC9CD9719B29A702%40DM6PR09MB4726.namprd09.prod.outlook.com.

Attachments:

• smime.p7s
  

[Alagic, Gorjan (Assoc)]

Hi Filippo and all,

 

After some internal discussion, the conclusion was:

• The FIPS 140-3 IG was not meant to cover this case.
• We are considering supporting this, but that would require revising SP 800-133. Here it would be helpful to hear more about use-cases of interest.

 

Best,

Gorjan

[Deirdre Connolly]

Great! An example would be the key derivation of the hybrid KEM X-Wing: we generate a 32-byte seed as our secret key, then expand it to 96 bytes via SHAKE256, and split those bytes into 64 bytes then passed to `ML-KEM.KeyGen_internal()` and 32 bytes as an X25519 secret key scalar:

https://www.ietf.org/archive/id/draft-connolly-cfrg-xwing-kem-06.html#name-key-generation

[Filippo Valsorda]

Hi Gorjan,

Great to hear you're considering this. I can offer two use cases.

First, if I'm designing a hybrid scheme I can just say "generate the two private keys according to the respective algorithms and store them how you see fit, read up on seed formats, you're on your own" but I would like to do better than that. I would like to be able to say "take a symmetric 256-bit derivation key, then apply this approved KDF with this label to obtain the ML-KEM seeds, and with this other label to obtain the ECDH scalar, here are some test vectors". The latter is more testable, easier to analyze as a whole, provides interoperability for private key encodings out of the box, and leaves less room for implementer error. It's also conveniently smaller. X-Wing is an example of this strategy.

Second, say I already have some key material stored for a user, which I currently pass to an approved KDF to derive some other keys. I would like to use the same KDF with a different label to derive ML-KEM keys for the user, without storing new keys with the complexity involved in it.

Cheers,

Filippo

[Bas Westerbaan]

Let me give an example of a widely deployed system that requires derived seeds.

FIDO2 tokens (eg. yubikeys and others supporting webauthn) use per website ("RP") keypairs. They're allowed to derive these deterministically from one master secret. Especially for hardware tokens with limited memory, as otherwise there would be a limit on the number of websites you could register the token with.

Best,

 Bas

To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/b307b949-7cf5-44ad-9b96-941ca61f0d66%40app.fastmail.com.

[Stephan Mueller]

Am Montag, 28. Oktober 2024, 09:50:20 Mitteleuropäische Normalzeit schrieb
Filippo Valsorda:

Hi,

The use case I can offer is the following. I would like to segment the use
case as the first complies with the initial request of this thread, whereas
the second extends that a bit to more real-world use cases.

The first use case covers the aspect where an existing key management
mechanism is in place which always managed and stored keys with 256 bit
(classic) security strength. For that, it stores for each key 256 bits of data
obtained from a fully seeded DRBG. Those 256 bit are used to derive any kind
of key, where each particular 256 bit data block is only dedicated for exactly
one of the following use cases:

- symmetric AES-256 keys by applying a KDF which inserts some system
properties (e.g. to bind it to the given properties)

- asymmetric ECC keys which again applies a KDF along with other system data

Such system now would need to be amended to cope with 512 bit seed material
just for ML-KEM knowing that there is no cryptographic relevance to require
512 bits. I.e. the whole data model for the key management system would need
to be amended to support such 512 bit data blocks instead of maintaining 256
bits and deriving 512 bits from it with a valid / sufficiently strong KDF /
DRBG.


In the second use case, the aforementioned consideration is extended by using
one initial 256 bit data block from the fully seeded DRBG to derive multiple
different keys. Naturally, the values derived from the original 256 bit seed
are subject to proper domain separation using proper KDF algorithms. This
approach is very common today when you have one "master secret" stored
somewhere well-protected in the hardware (e.g. fuses which are blown during
chip manufacturing by the DRBG on the same chip) and one wants to construct a
key hierarchy based on that "master secret" during boot time or runtime.

Such constructions are commonplace today, including the DICE key hierarchy
specification as well as proprietary key hierarchy constructions anchored in
the master secret.

With the presence of PQC including ML-KEM, now such PQC key pairs may be
constructed as part of the key hierarchy from that master secret.

Ciao
Stephan

[John Mattsson]

>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.

I would like to see 800-133 updated to allow this. Especially for the use case mentioned by Deirdre, X25519+ML-KEM hybrids. I think having a 32 byte seed s and deriving things from that with SHAKE256 is the correct way to implement things.

Using the same approach of generating a 32-byte seed s and using that to generate keys for Ed25519+ML-DSA or Ed448+ML-DSA hybrids seems to make equal sense to me.

Cheers,
John

 

From: 'Stephan Mueller' via pqc-forum <pqc-...@list.nist.gov>
Date: Wednesday, 30 October 2024 at 18:19
To: Gorjan (Assoc) Alagic <gorjan...@nist.gov>, pqc-forum <pqc-...@list.nist.gov>
Cc: Deirdre Connolly <durumcr...@gmail.com>, Blumenthal, Uri - 0553 - MITLL <u...@ll.mit.edu>, Phillip Hallam-Baker <ph...@hallambaker.com>, Tony Arcieri <bas...@gmail.com>, Filippo Valsorda <fil...@ml.filippo.io>, xiaoy...@intel.com <xiaoy...@intel.com>
Subject: Re: [pqc-forum] Re: ML-KEM: usage of seed for key pair generation

--
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://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fa%2Flist.nist.gov%2Fd%2Fmsgid%2Fpqc-forum%2F3065682.sbSiNAyKp5%2540tauon.atsec.com&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C5777438a4266446859a308dcf9070763%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638659055791453238%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=en8wg4QLNvcePiivAAoKnpYowT4u2%2Bqy64N%2BtF%2FiUe4%3D&reserved=0.

[Mike Ounsworth]

Hi Gorjan,

 

Does NIST have someone who will be attending IETF next week in Dublin? Quynh Dang often attends.

 

The IETF owns several private key container formats such as PKCS#12 and JWK. I suspect that how to represent ML-DSA and ML-KEM private keys (seed vs full) will be a major discussion point next week across a number of IETF working groups. If you’re looking for use-cases, I’m sure that many will come up during the IETF meetings.

 

Knowing that seed is not (currently) supported by FIPS is unfortunate yet useful input for these IETF discussions.

 

---

Mike Ounsworth

Using only a 32-byte seed for ML-KEM is not allowed by FIPS 203, and we have no plans to allow it. It’s true that having such an option might be advantageous for some applications. However, we do not see this as a sufficient reason to change FIPS 203, either directly or indirectly. Making a change at this stage is no small task, and could have unintended consequences. – Gorjan (for NIST PQC team).

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

[Orie Steele]

+1 to John's note.

I would like to see 800-133 updated to allow expansion of (d,z) from a single 32-byte seed (s) using some approved functions.

(or some generalization of this framing)

Applying this approach to hybrids is very interesting, but perhaps better addressed in dedicated documents on hybrid construction and composite key generation that could reference an updated 800-133.

Is this forum the right venue for that discussion?

(I don't want to derail the discussion of ml-kem seeds here).

OS

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

--

ORIE STEELE
Chief Technology Officer
www.transmute.industries

[Deirdre Connolly]

FIPS 203 is contradictory on this, but as of this moment, the `_internal()` algorithms are actually being tested by ACVP, so it seems the seed format for keys in an implementation will be FIPS-validate-able

https://github.com/usnistgov/ACVP/pull/1531/files

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

[Deirdre Connolly]

But yes allowing derived values for the seed formats instead of the DRBG values needs clarifying 

[Bas Westerbaan]

Mike,

Perhaps John's quote confused you, but it seems to me that Gorjan stated that using the 64-byte (for ML-KEM) and 32-byte (for ML-DSA) seed is allowed. What is not allowed (yet!) is deriving those seeds deterministically from some other master seed.

See the original e-mail: https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/949fsZRC6Ik/m/QUaAPyhSAAAJ

Notwithstanding, I agree with your request.

Best,

 Bas

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

[Scott Fluhrer (sfluhrer)]

Deidre, the problem is that, according to FIPS 203 (section 6):

 

As prescribed in Section 3.3, the interfaces specified in this section should not be made available to applications other than for testing purposes, and the random seeds (as specified in ML-KEM.KeyGen and ML-KEM.Encaps in Section 7) shall be generated by the cryptographic module.

 

If the random seeds have to be generated by the cryptographic module, it would appear to ban the import of them (at least by my reading of the text).  However, the sentence previous to the one I quoted specifically allows the local storage of the seed within the cryptographic module (and reexpansion at decaps time).

 

Mike has asked NIST about transferring the seed as the private key between modules, and their immediate response was “good question – we’ll get back to you on that”.

 

Now, Quynh will be in Dublin, and so we could interrogate him.  However, I don’t expect him to be willing to speak on behalf of NIST…

 

(I personally think that passing seeds as the private key is quite reasonable and I don’t see a downside – however, NIST sometimes disagrees with me…)

 

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

[Mike Ounsworth]

Ah yes. I got confused about what “this” is in Gorjan’s statement “We are considering supporting this”. Thanks for the correction.

 

 

I still don’t think that Gorjan has provided a complete answer. The same question exists for ML-DSA, and I don’t think NIST has addressed this. Specifically I don’t think he’s addressed the language in FIPS in FIPS 204 section 6:

 

"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, to my reading, seems pretty clear that you can’t import an ML-DSA private key as seed from outside the crypto module (for example, via reading a p12 file provided by a user).

 

I think that for IETF purposes, having different private key formats for ML-DSA and ML-KEM would be … weird.

---

Mike Ounsworth

 

From: Bas Westerbaan <b...@cloudflare.com>

Sent: Wednesday, October 30, 2024 1:16 PM
To: Mike Ounsworth <Mike.Ou...@entrust.com>

[Deirdre Connolly]

💯, thanks Quynh!

On Wed, Oct 30, 2024 at 2:36 PM Dang, Quynh H. (Fed) <quynh...@nist.gov> wrote:

Hi Scott,

 

From: 'Scott Fluhrer (sfluhrer)' via pqc-forum <pqc-...@list.nist.gov>
Sent: Wednesday, October 30, 2024 2:27 PM
To: Deirdre Connolly <durumcr...@gmail.com>; Mike Ounsworth <Mike.Ou...@entrust.com>
Cc: Alagic, Gorjan (Assoc) <gorjan...@nist.gov>; Filippo Valsorda <fil...@ml.filippo.io>; Blumenthal, Uri - 0553 - MITLL <u...@ll.mit.edu>; Phillip Hallam-Baker <ph...@hallambaker.com>; Tony Arcieri <bas...@gmail.com>; pqc-forum <pqc-...@list.nist.gov>
Subject: RE: [pqc-forum] Re: ML-KEM: usage of seed for key pair generation

 

Deidre, the problem is that, according to FIPS 203 (section 6):

 

As prescribed in Section 3.3, the interfaces specified in this section should not be made available to applications other than for testing purposes, and the random seeds (as specified in ML-KEM.KeyGen and ML-KEM.Encaps in Section 7) shall be generated by the cryptographic module.

 

If the random seeds have to be generated by the cryptographic module, it would appear to ban the import of them (at least by my reading of the text). 

[Dang, Quynh H. (Fed)] I am not sure if the text means not allowing to pass (d, z) from one module to another. I’ll ask my team.

 

Regards,

Quynh.

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

[Filippo Valsorda]

2024-10-30 19:36 GMT+01:00 Dang, Quynh H. (Fed) <quynh...@nist.gov>:

Hi Scott,

 

From: 'Scott Fluhrer (sfluhrer)' via pqc-forum <pqc-...@list.nist.gov>

Sent: Wednesday, October 30, 2024 2:27 PM

To: Deirdre Connolly <durumcr...@gmail.com>; Mike Ounsworth <Mike.Ou...@entrust.com>
Cc: Alagic, Gorjan (Assoc) <gorjan...@nist.gov>; Filippo Valsorda <fil...@ml.filippo.io>; Blumenthal, Uri - 0553 - MITLL <u...@ll.mit.edu>; Phillip Hallam-Baker <ph...@hallambaker.com>; Tony Arcieri <bas...@gmail.com>; pqc-forum <pqc-...@list.nist.gov>
Subject: RE: [pqc-forum] Re: ML-KEM: usage of seed for key pair generation

 

Deidre, the problem is that, according to FIPS 203 (section 6):

 

As prescribed in Section 3.3, the interfaces specified in this section should not be made available to applications other than for testing purposes, and the random seeds (as specified in ML-KEM.KeyGen and ML-KEM.Encaps in Section 7) shall be generated by the cryptographic module.

 

If the random seeds have to be generated by the cryptographic module, it would appear to ban the import of them (at least by my reading of the text). 

[Dang, Quynh H. (Fed)] I am not sure if the text means not allowing to pass (d, z) from one module to another. I’ll ask my team.

Hi all,

The interpretation that (d, z) seeds can be stored internally but not passed from one module to another makes no sense: usually a module wants to expand a key internally, not compress it. Seeds are a great format for interchange, because they reduce the margin of error and the required validation on import, and it's great that NIST amended the final FIPS 203 to explicitly allow them.

The idea that FIPS 203 was amended to explicitly allow expanding (d, z) but only for keys generated within the same module is sort of reverse malicious compliance, and I don't know why we'd make our collective life hard by interpreting it like that, but in this case it's especially dangerous because it might lead the IETF to standardize non-seed formats and then we'll be carrying that complexity across implementations for decades to come.

We already implemented our ML-KEM API in Go to use seeds, and we're weeks away from validation. This is very late to make any changes. I know of at least two other libraries that already went with seeds. It's not a backwards compatible change either: a key imported as expanded can't be exported as seed (another reason this interpretation makes no sense: it would not work at all with imported keys).

Filippo

Regards,

Quynh.

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

[Simo Sorce]

On Wed, 2024-10-30 at 18:29 +0000, 'Mike Ounsworth' via pqc-forum
wrote:

>  
>
> Which, to my reading, seems pretty clear that you can’t import an ML-DSA private key as seed from outside the crypto module (for example, via reading a p12 file provided by a user).
>

It is not clear why you are conflating these things.

If you import a seed that has been generated by a validated module and
exported wrapped via something like AES-KW, then you are not making any
internal function available to the application.

You are making a key import service available to the application, and
this service uses the internal functions.

And probably even allowing "clear text" secrets import would lead me to
the same conclusion.

In any import scenario (including importing fully expanded private
keys) you can't make any inference as to what generated the seed and
how. But then that shouldn't really matter because you are not
performing a key generation operation but rather an import operation.

It is on the module's user to assure the private key that is being
imported was generated according to FIPS requirements.

Otherwise you would never be able to import any private key at all.

--
Simo Sorce
Distinguished Engineer
RHEL Crypto Team
Red Hat, Inc

[Mike Ounsworth]

By the way, I am going to suggest at IETF LAMPS next week that given the current state of all this, we should support in PKCS#8 / PKCS#12 in the following way:

 

 

ML-*PrivateKeySeed ::= OCTET STRING (SIZE X) -- X is 32 for ML-DSA and 64 for ML-KEM

 

ML-*PrivateKeyFull ::= OCTET STRING

 

ML-*PrivateKey ::= CHOICE {
          ML-*PrivateKeySeed,
      [0] ML-*PrivateKeyFull }

 

(where ML-* means ML-DSA or ML-KEM)

 

IE make Seed the default private key format, and do it in such a way that if your application never expects to encounter a full key, then ML-*PrivateKey is binary identical to ML-*PrivateKeySeed. But if some crypto module only has the full seed then there at least is a standardized format for it.

 

I don’t love it, for the same reasons that you mention Filippo, but since FIPS 203 / 204 allow crypto modules to store expanded keys, I think we will need to support ways to export those.

 

---

Mike Ounsworth

 

From: Filippo Valsorda <fil...@ml.filippo.io>
Sent: Wednesday, October 30, 2024 2:00 PM
To: Dang, Quynh H. (Fed) <quynh...@nist.gov>; Scott Fluhrer (sfluhrer) <sflu...@cisco.com>; Deirdre Connolly <durumcr...@gmail.com>; Mike Ounsworth <Mike.Ou...@entrust.com>
Cc: Gorjan (Assoc) Alagic <gorjan...@nist.gov>; Blumenthal, Uri - 0553 - MITLL <u...@ll.mit.edu>; Phillip Hallam-Baker <ph...@hallambaker.com>; Tony Arcieri <bas...@gmail.com>; pqc-forum <pqc-...@list.nist.gov>
Subject: [EXTERNAL] Re: [pqc-forum] Re: ML-KEM: usage of seed for key pair generation

 

2024-10-30 19: 36 GMT+01: 00 Dang, Quynh H. (Fed) <quynh. dang@ nist. gov>: Hi Scott, From: 'Scott Fluhrer (sfluhrer)' via pqc-forum <pqc-forum@ list. nist. gov> Sent: Wednesday, October 30, 2024 2: 27 PM To: Deirdre Connolly <durumcrustulum@ gmail. com>;

[Sophie Schmieg]

On Wed, Oct 30, 2024 at 8:41 PM 'Mike Ounsworth' via pqc-forum <pqc-...@list.nist.gov> wrote:

By the way, I am going to suggest at IETF LAMPS next week that given the current state of all this, we should support in PKCS#8 / PKCS#12 in the following way:

 

 

ML-*PrivateKeySeed ::= OCTET STRING (SIZE X) -- X is 32 for ML-DSA and 64 for ML-KEM

 

ML-*PrivateKeyFull ::= OCTET STRING

 

ML-*PrivateKey ::= CHOICE {
          ML-*PrivateKeySeed,
      [0] ML-*PrivateKeyFull }

 

(where ML-* means ML-DSA or ML-KEM)

 

IE make Seed the default private key format, and do it in such a way that if your application never expects to encounter a full key, then ML-*PrivateKey is binary identical to ML-*PrivateKeySeed. But if some crypto module only has the full seed then there at least is a standardized format for it.

 

I don’t love it, for the same reasons that you mention Filippo, but since FIPS 203 / 204 allow crypto modules to store expanded keys, I think we will need to support ways to export those.

 

"I don't love it" sounds like a severe understatement. Note that IETF, like NIST, has a certain amount of normative power here. If IETF simply does not support modules that export keys in the expanded format, then that is its pejorative. For example, TLS 1.3 does not allow anything but 12 byte nonces and 16 byte tags for AES-GCM, even though any nonce length and various different tag lengths are explicitly allowed in SP 800-38D. Just because there might be FIPS compliant modules out there that only support expanded keys, is not enough reason to shoehorn in support like this into certificates, especially not this early in the lifetime of ML-KEM/ML-DSA, where almost no module exists yet, and module designers are looking to standardization bodies for guidance on this type of question. IETF standards picking and choosing from NIST standards in ways that are most suitable for the protocol question at hand is the system working as intended, in my opinion, and for LAMPS, choosing seed-only seems the most prudent option in the case of X509 certificate private keys.

As for the concern that the "seed-only" private key might be internal to the module only: This contradicts the explicit reason given for explicitly allowing the seed in FIPS 203, which was to enable protocol designers to mitigate this issues identified by Cramer et al. in "Keeping up with the KEMs" [1], and myself in "Unbindable Kemmy Schmidt" [2]. Keeping the seed internal to a module does not do that. In fact, modules usually represent key material internally in the way that is most convenient to them, that is the whole point of the module abstraction, which allows mathematically identical internal differences in implementations. We can see further evidence of this idea when we look at how true prehashing in ML-DSA is accomplished in Algorithm 7, line 6. Algorithm 7 is one of these "internal to module only" functions, yet the comment on this line explicitly allows the computation of µ to happen in a different module, showing that two modules can cooperate even across "internal" functions, as long as this complexity is not exposed to the caller. Similarly, the 64 byte seed has to be generated by a module, and can be passed to another module, i.e. serve as a private key format. The seed on the other hand must not be generated by the application logic, since using anything but 64 (pseudo)random bytes would make the private key compromised, and the generation of (pseudo)random bytes is best left to the cryptographic module. (Note that "pseudorandom" unfortunately seems to require additional clarification by NIST, which hopefully comes soon, so we can derive ML-KEM/ML-DSA keys)

[1] https://eprint.iacr.org/2023/1933

[2] https://eprint.iacr.org/2024/523

--

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

[Mike Ounsworth]

One other factor to consider is that if we allow expanded ML-* private keys in PKCS#11 (HSM interfaces) but only seed keys in PKCS#12 (.p12 files) then I foresee problems where HSM vendors will export expanded keys and then software will be incapable of converting that into an interoperable private key file.

I think we need coordination here between IETF LAMPS who own P12 and OASIS PCKS11 committee. Is anyone on the OASIS P11 committee and willing to volunteer to collaborate on this?

---

Mike Ounsworth

---

From: 'Sophie Schmieg' via pqc-forum <pqc-...@list.nist.gov>
Sent: Thursday, October 31, 2024 3:57:06 AM
To: Mike Ounsworth <Mike.Ou...@entrust.com>
Cc: Filippo Valsorda <fil...@ml.filippo.io>; Dang, Quynh H. (Fed) <quynh...@nist.gov>; Scott Fluhrer (sfluhrer) <sflu...@cisco.com>; Deirdre Connolly <durumcr...@gmail.com>; Gorjan (Assoc) Alagic <gorjan...@nist.gov>; Blumenthal, Uri - 0553 - MITLL <u...@ll.mit.edu>; Phillip Hallam-Baker <ph...@hallambaker.com>; Tony Arcieri <bas...@gmail.com>; pqc-forum <pqc-...@list.nist.gov>
Subject: Re: [EXTERNAL] Re: [pqc-forum] Re: ML-KEM: usage of seed for key pair generation

 

On Wed, Oct 30, 2024 at 8: 41 PM 'Mike Ounsworth' via pqc-forum <pqc-forum@ list. nist. gov> wrote: By the way, I am going to suggest at IETF LAMPS next week that given the current state of all this, we should support in PKCS#8 / PKCS#12

--
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/CAEEbLAb5RLf4mrus%3DXBZ0RWGQTR5EHLfq%3D_E4WeN_GvbS-DOdg%40mail.gmail.com.

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.

[JOHNSON Darren]

THALES GROUP LIMITED DISTRIBUTION to email recipients

 

Hi,

I’m on the committee and can help out.  I know a number of the people on the P11 committee are on these threads as well.  I can certainly offer my thoughts on the topic. But I can also collect/coordinate the input from the committee on this topic.

 

Do we want to continue that specific discussion on this thread, on a separate thread, or as a separate discussion?

 

--

Darren Johnson

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

[Jeff Andersen]

The proposal would be to only support seed formats in both PKCS#11 and PKCS#12, so that security doesn't stand in the way of interoperability?

--Jeff Andersen

To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/MR1P264MB213214F1CA70FAD2CA7054AD9C552%40MR1P264MB2132.FRAP264.PROD.OUTLOOK.COM.

[Mike Ounsworth]

Thanks Darren! Good question about the right way to do collaboration. Maybe we wait to see on this thread who wants to participate in such a discussion on synchronizing ML private key formats between PKCS#11 and #12, and then we drop to a private email thread?

And Jeff, yes, that's exactly what I'm thinking. Seed mode is better, but I fear that if one of PKCS#11 or #12 decides to support expanded private keys, then the other will have to as well.

---

Mike Ounsworth

---

From: Jeff Andersen <jeffan...@google.com>
Sent: Thursday, October 31, 2024 1:32:57 PM
To: JOHNSON Darren <darren....@thalesgroup.com>
Cc: Mike Ounsworth <Mike.Ou...@entrust.com>; Sophie Schmieg <ssch...@google.com>; Filippo Valsorda <fil...@ml.filippo.io>; Dang, Quynh H. (Fed) <quynh...@nist.gov>; Scott Fluhrer (sfluhrer) <sflu...@cisco.com>; Gorjan (Assoc) Alagic <gorjan...@nist.gov>; pqc-forum <pqc-...@list.nist.gov>

Subject: Re: [EXTERNAL] Re: [pqc-forum] Re: ML-KEM: usage of seed for key pair generation

 

The proposal would be to only support seed formats in both PKCS#11 and PKCS#12, so that security doesn't stand in the way of interoperability? --Jeff Andersen On Thu, Oct 31, 2024 at 1: 30 PM 'JOHNSON Darren' via pqc-forum <pqc-forum@ list. nist. gov>

[Jeff Andersen]

Disclaimer: I'm unfamiliar with the PKCS#11 ecosystem.

If PKCS#11 defines functions for exporting keys in both seed and expanded format, is it expected that HSMs will generally support both functions? Or do vendors have latitude in deciding which function they will implement?

If vendors would generally support both functions, then it seems that the user would just need to pick the function that gives them the key in the correct format if their use-case involves PKCS#12 (which could then only support the seed format).

--Jeff Andersen

[Simo Sorce]

On Thu, 2024-10-31 at 16:59 +0000, 'Mike Ounsworth' via pqc-forum
wrote:

> One other factor to consider is that if we allow expanded ML-* private keys in PKCS#11 (HSM interfaces) but only seed keys in PKCS#12 (.p12 files) then I foresee problems where HSM vendors will export expanded keys and then software will be incapable of converting that into an interoperable private key file.
>
> I think we need coordination here between IETF LAMPS who own P12 and OASIS PCKS11 committee. Is anyone on the OASIS P11 committee and willing to volunteer to collaborate on this?

I can work with you on this from the OASIS PKCS#11 side.

Simo.

> ---
> Mike Ounsworth
> ________________________________
> From: 'Sophie Schmieg' via pqc-forum <pqc-...@list.nist.gov>
> Sent: Thursday, October 31, 2024 3:57:06 AM
> To: Mike Ounsworth <Mike.Ou...@entrust.com>
> Cc: Filippo Valsorda <fil...@ml.filippo.io>; Dang, Quynh H. (Fed) <quynh...@nist.gov>; Scott Fluhrer (sfluhrer) <sflu...@cisco.com>; Deirdre Connolly <durumcr...@gmail.com>; Gorjan (Assoc) Alagic <gorjan...@nist.gov>; Blumenthal, Uri - 0553 - MITLL <u...@ll.mit.edu>; Phillip Hallam-Baker <ph...@hallambaker.com>; Tony Arcieri <bas...@gmail.com>; pqc-forum <pqc-...@list.nist.gov>
> Subject: Re: [EXTERNAL] Re: [pqc-forum] Re: ML-KEM: usage of seed for key pair generation
>
> On Wed, Oct 30, 2024 at 8: 41 PM 'Mike Ounsworth' via pqc-forum <pqc-forum@ list. nist. gov> wrote: By the way, I am going to suggest at IETF LAMPS next week that given the current state of all this, we should support in PKCS#8 / PKCS#12
>
>
>
> On Wed, Oct 30, 2024 at 8:41 PM 'Mike Ounsworth' via pqc-forum <pqc-...@list.nist.gov<mailto:pqc-...@list.nist.gov>> wrote:
>
> By the way, I am going to suggest at IETF LAMPS next week that given the current state of all this, we should support in PKCS#8 / PKCS#12 in the following way:
>
>
>
>
>
> ML-*PrivateKeySeed ::= OCTET STRING (SIZE X) -- X is 32 for ML-DSA and 64 for ML-KEM
>
>
>
> ML-*PrivateKeyFull ::= OCTET STRING
>
>
>
> ML-*PrivateKey ::= CHOICE {
> ML-*PrivateKeySeed,
> [0] ML-*PrivateKeyFull }
>
>
>
> (where ML-* means ML-DSA or ML-KEM)
>
>
>
> IE make Seed the default private key format, and do it in such a way that if your application never expects to encounter a full key, then ML-*PrivateKey is binary identical to ML-*PrivateKeySeed. But if some crypto module only has the full seed then there at least is a standardized format for it.
>
>
>
> I don’t love it, for the same reasons that you mention Filippo, but since FIPS 203 / 204 allow crypto modules to store expanded keys, I think we will need to support ways to export those.
>
>
>
> "I don't love it" sounds like a severe understatement. Note that IETF, like NIST, has a certain amount of normative power here. If IETF simply does not support modules that export keys in the expanded format, then that is its pejorative. For example, TLS 1.3 does not allow anything but 12 byte nonces and 16 byte tags for AES-GCM, even though any nonce length and various different tag lengths are explicitly allowed in SP 800-38D. Just because there might be FIPS compliant modules out there that only support expanded keys, is not enough reason to shoehorn in support like this into certificates, especially not this early in the lifetime of ML-KEM/ML-DSA, where almost no module exists yet, and module designers are looking to standardization bodies for guidance on this type of question. IETF standards picking and choosing from NIST standards in ways that are most suitable for the protocol question at hand is the system working as intended, in my opinion, and for LAMPS, choosing seed-only seems the most prudent option in the case of X509 certificate private keys.
>
> As for the concern that the "seed-only" private key might be internal to the module only: This contradicts the explicit reason given for explicitly allowing the seed in FIPS 203, which was to enable protocol designers to mitigate this issues identified by Cramer et al. in "Keeping up with the KEMs" [1], and myself in "Unbindable Kemmy Schmidt" [2]. Keeping the seed internal to a module does not do that. In fact, modules usually represent key material internally in the way that is most convenient to them, that is the whole point of the module abstraction, which allows mathematically identical internal differences in implementations. We can see further evidence of this idea when we look at how true prehashing in ML-DSA is accomplished in Algorithm 7, line 6. Algorithm 7 is one of these "internal to module only" functions, yet the comment on this line explicitly allows the computation of µ to happen in a different module, showing that two modules can cooperate even across "internal" functions, as long as this complexity is not exposed to the caller. Similarly, the 64 byte seed has to be generated by a module, and can be passed to another module, i.e. serve as a private key format. The seed on the other hand must not be generated by the application logic, since using anything but 64 (pseudo)random bytes would make the private key compromised, and the generation of (pseudo)random bytes is best left to the cryptographic module. (Note that "pseudorandom" unfortunately seems to require additional clarification by NIST, which hopefully comes soon, so we can derive ML-KEM/ML-DSA keys)
>

> [1] https://eprint.iacr.org/2023/1933<https://urldefense.com/v3/__https://eprint.iacr.org/2023/1933__;!!FJ-Y8qCqXTj2!cKrQ1FIUihliHKbJdQt9GTOr0BeNiJrS9EcTxzvKCjJ-qUWGE-S6OA4Ps8Z_5GkwzER27CScL99PU67N4w4PxxKYS8JG$>
> [2] https://eprint.iacr.org/2024/523<https://urldefense.com/v3/__https://eprint.iacr.org/2024/523__;!!FJ-Y8qCqXTj2!cKrQ1FIUihliHKbJdQt9GTOr0BeNiJrS9EcTxzvKCjJ-qUWGE-S6OA4Ps8Z_5GkwzER27CScL99PU67N4w4Px14t3Kdr$>
>
> --
>
> Sophie Schmieg | Information Security Engineer | ISE Crypto | ssch...@google.com<mailto: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<mailto:pqc-forum+...@list.nist.gov>.
> To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CAEEbLAb5RLf4mrus%3DXBZ0RWGQTR5EHLfq%3D_E4WeN_GvbS-DOdg%40mail.gmail.com<https://urldefense.com/v3/__https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/CAEEbLAb5RLf4mrus*3DXBZ0RWGQTR5EHLfq*3D_E4WeN_GvbS-DOdg*40mail.gmail.com?utm_medium=email&utm_source=footer__;JSUl!!FJ-Y8qCqXTj2!cKrQ1FIUihliHKbJdQt9GTOr0BeNiJrS9EcTxzvKCjJ-qUWGE-S6OA4Ps8Z_5GkwzER27CScL99PU67N4w4Px9jT50LC$>.

> 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.
>

[Deirdre Connolly]

> Using the same approach of generating a 32-byte 

seed s and using that to generate keys for Ed25519+ML-DSA or Ed448+ML-DSA hybrids seems to make equal sense to me.

💯

[Gorjan Alagic]

Hi all,

This thread now seems to mix both the (potential) 32-byte ML-KEM seed option *and* general questions about seed usage for ML-KEM and ML-DSA. I think it would be better to discuss only the former topic here. I replied regarding the latter topic in the other thread (https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/949fsZRC6Ik).

Best,
Gorjan

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