[lamps] Re: [EXT] Re: Seed as private key for ML-DSA and ML-KEM

[Sophie Schmieg <[e-mail]>]

I definitely prefer 4. Just using seeds simplifies things, and addresses
misbinding issues, allowing us to sidestep any discussion of whether they
are important or not.
The half-expanded format for ML-KEM private keys is IMHO an artifact of the
way microbenchmarks are defined, and do not align with realistic usage of
ML-KEM, where the private key either is never serialized (ephemeral
setting) or deserialized once and then used multiple times over the
lifetime of a process, amortizing deserialization costs (static setting).
On top of that, the half-expanded private key does not cache the most
expensive operation of expanding the matrix anyways, so the performance
difference is fairly marginal as is.

Note that "always use seeds" does not imply that implementations cannot
have their own expanded in-memory representation (in fact it all but
requires that), and that by extension hardware implementation might also
operate on an expanded representation of the key material, even if it is
not strictly speaking in RAM. The seed is used for the serialized transport
only.

See also Fillipo's write-up:
https://words.filippo.io/dispatches/ml-kem-seeds/#fnref5

On Wed, Aug 21, 2024 at 9:13 AM Blumenthal, Uri - 0553 - MITLL <
[e-mail]> wrote:

> I prefer option 2, followed by option 4.
>
> Thanks
> —
> Regards,
> Uri
>
> Secure Resilient Systems and Technologies
> MIT Lincoln Laboratory
>
> > On Aug 21, 2024, at 12:02, Russ Housley <[e-mail]> wrote:
> >
> > !-------------------------------------------------------------------|
> >  This Message Is From an External Sender
> >  This message came from outside the Laboratory.
> > |-------------------------------------------------------------------!
> >
> > Bas:
> >
> > I also prefer option 4.  That is, always thranser as a seed, but allow
> an implementation to internal store in whatever works best for them.
> >
> > Russ
> >
> >> On Aug 21, 2024, at 11:50 AM, Bas Westerbaan <bas=
> [e-mail]> wrote:
> >>
> >> Hi all,
> >>
> >> NIST allows two formats in which private keys are stored ML-DSA and
> ML-KEM.
> >>
> >> 1. Seed. 32 bytes for ML-DSA; 64 bytes for ML-KEM.
> >> 2. Expanded private key. Multiple kilobytes depending on instance.
> >>
> >> An expanded private key is obtained from the seed by calling the
> KeyGen_internal function.
> >>
> >> In contrast to RSA, key generation for these algorithms is very fast.
> In fact, if you use spinning disks, then using a seed is probably faster
> than the expanded private key.
> >>
> >> Another advantage is that we do not need to worry about private key
> validation. NIST specified a few checks to perform, but there are more we
> could do (eg. whether the decoded coefficients of \hat{s} are bounded.)
> >>
> >> Of course a big advantage is storage space: the seeds are much smaller.
> >>
> >> Now, how do we want to proceed? I see a few options.
> >>
> >> 1. Ignore the seed as private key.
> >>
> >> 2. Allow both seed and the expanded private key.
> >>
> >> 3. Assign separate algorithm for seed-as-private-key.
> >>
> >> 4. Switch to seed as private key only.
> >>
> >> I prefer 4, and would otherwise go for 1.
> >>
> >> The downside of 2 is that it adds complexity without the gain of
> simplifying verification. If one only cares about size savings, then one
> can use seed-as-private-key without needing a portable format for it.
> >>
> >> So I'd prefer 4 and 1 second.
> >>
> >> Best,
> >>
> >> Bas
> >> _______________________________________________
> >> Spasm mailing list -- [e-mail]
> >> To unsubscribe send an email to [e-mail]
> >
> > _______________________________________________
> > Spasm mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> _______________________________________________
> Spasm mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>


-- 

Sophie Schmieg | Information Security Engineer | ISE Crypto |
[e-mail]