Also this is just in from PQC-Froum:
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.
So I would say there is no "normative" issue here.
On Fri, 2024-11-01 at 10:29 -0400, Simo Sorce wrote:
> Some comments on Tim's reply follow, but the reason we are raising
> this is that there is a good chance some protocols will want to
> define at least ML-KEM and ML-DSA import/export methods to use seeds
> for storage/transmission.
>
> Specifically PKCS#12 files have been explicitly metioned.
>
> And the fact is you can always seed -> private-key and you can never
> private-key -> seed. So storing the seeds to be able to properly
> export keys *should* definitely be a strong consideration here.
>
>
> On Thu, 2024-10-31 at 21:21 +0000, Tim Hudson via OASIS wrote:
> > I'd rephrase that as there is a very small group of people
> > that are pushing the concept that private keys should never
> > be encoded and should always be derived from an input seed.
>
> Not sure it matters if they are relatively many or a few, there are
> influential people in IETF that lean that way. And I think they have
> reasonable arguments too.
>
> > The concept of requiring a seed value to always be present
> > is simply not generally supportable and makes little sense
> > when you work through all the possible contexts of usage.
>
> I am not sure I understand this point, given the seed you can
> always regenerate the key, so it should be generally supportable.
> Of course some implementations may want to permanently store the
> expanded keys as well for performance reasons, but if you can
> store the expanded key, storing along side it the generation seed
> to be used as an export format is not a big deal.
>
> > Those who are pushing that concept are doing so in the context
> > of keys being ephemeral and mostly in the context of ML-KEM
> > and to not have to define a persistent key format and that the
> > "generation" cost is trivial. This isn't generally applicable.
>
> What part is not generally applicable? That generation cost is high?
>
> In any case that is not the only argument. Many make the argument that
> storing seeds is much simpler for small devices as it reduces the size
> of permanent storage and regenerating the key doubles as a test that
> the key is well formed which is an operation you need to do for FIPS
> certified modules.
> Storing seeds also reduces ambiguity and allows implementations to
> organize the expanded format as they see fit.
>
> > And to be exceedingly clear, there is absolutely no requirement
> > or suggesting within any of the NIST specifications that
> > implementations should operate off a SEED value and see that
> > as the private key
>
> I have seen no one make this argument, so I do not see the relevance
> TBH.
>
> > - and in fact the concept of an externally provided seed does not
> > universally exist in the NIST docs. Basically you end up seeing a
> > "seed" as the PRNG output values in some algorithms and they are
> > not defined as an alternate input key generation mechanism.
>
> I this case it would be key re-constitution, and not generation.
> The key generation happened the first time when the seed was
> actually generated.
>
> > FIPS-203 (allows for the concept that implementations might
> > choose to store the seed in place of the private key but does
> > not require that this be supported - and it is clear it is a
> > SEED not a private key value format)
>
> It is clear the SEED is a seed, it is also clear it is as sensitive
> and equivalent to the private key. if you have access to the seed
> you know the private key.
>
> > There is also an explicit note: As prescribed in Section 3.3,
> > the interfaces specified in this section should not be made
> > available to applications other than for testing purposes,
>
> I do not see the relevance of this, private key re-computation
> from a seed would be an internal operation anyway.
>
> > and the random seeds (as specified in ML-KEM.KeyGen and
> > ML-KEM.Encaps in Section 7) shall be generated by the
> > cryptographic module.
>
> And so they shall, I do not get what point you are trying to
> make here? Care to elaborate ?
>
> > FIPS-204 (no seed input defined, you are changing the
> > internal algorithm RNG output)
>
> Look at Algorithm 6. The first line is:
>
> Input: Seed 𝜉 ∈ 𝔹32
>
>
> So input seed is clearly defined.
>
> > FIPS-205 (no seed input defined, you are changing the
> > internal algorithm RNG output)
>
> In 205 there isn't a single seed indeed, but there is a seed and a prf
> for public keys and a seed and root for the public key, but then again
> I have seen nobody claiming we need to use seed storage for SLH-DSA,
> only for ML-DSA and ML-KEM.
>
>
> HTH,
> Simo.
>
>
> Simo Sorce
> Distinguished Engineer
> RHEL Crypto Team
> Red Hat, Inc
--
Simo Sorce
Distinguished Engineer
RHEL Crypto Team
Red Hat, Inc
Original Message:
Sent: 10/31/2024 5:22:00 PM
From: Tim Hudson
Subject: RE: Private values for ML-DSA and similar
[Simo Sorce]
> There is quite a lot of people that think private keys should always be
> stored as seed values and reconstructed when read into memory.
I'd rephrase that as there is a
very small group of people that are pushing the concept that private keys should never be encoded and should always be derived from an input seed.
The concept of requiring a seed value to always be present is simply not generally supportable and makes little sense when you work through all the possible contexts of usage.
Those who are pushing that concept are doing so in the context of keys being ephemeral and mostly in the context of ML-KEM and to not have to define a persistent key format and that the "generation" cost is trivial. This isn't generally applicable.
And to be exceedingly clear, there is absolutely no requirement or suggesting within any of the NIST specifications that implementations should operate off a SEED value and see that as the private key - and in fact the concept of an externally provided seed does not universally exist in the NIST docs. Basically you end up seeing a "seed" as the PRNG output values in some algorithms and they are not defined as an alternate input key generation mechanism.
FIPS-203 (allows for the concept that implementations might choose to store the seed in place of the private key but does not require that this be supported - and it is clear it is a SEED not a private key value format)
There is also an explicit note: 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.
FIPS-204 (no seed input defined, you are changing the internal algorithm RNG output)
FIPS-205 (no seed input defined, you are changing the internal algorithm RNG output)
Original Message:
Sent: 10/31/2024 3:11:00 PM
From: Simo Sorce
Subject: Private values for ML-DSA and similar
So prompted by a discussion on the PQC Forum I was looking at our
definition of CKA_VALUE for ML-DSA and it says:
Big Integer: Private value as defined in [FIPS 204]
However FIPS 204 does not define "Private Value" in the glossary.
and mentions private values only in the part that explains ML-DSA
construction to define two private values (S1, S2) that constitute the
private key.
In order to ensure maximum interoperability the implementation should
definitely be able to get as input (on import) a Seed value that is
used to then reconstitute the full private key, and be able to always
export a seed value.
There is quite a lot of people that think private keys should always be
stored as seed values and reconstructed when read into memory.
In any case the current text is not clear enough and needs improvement
to avoid interoperability issues.
We should discuss this at the next meeting if possible.
Simo.
--
Simo Sorce
Distinguished Engineer
RHEL Crypto Team
Red Hat, Inc