[openpgp] Re: ML-KEM and ML-DSA secret key format

Aron Wussler <[email protected]> Thu, 27 Feb 2025 17:01:47 +0000
Newsgroups	gmane.ietf.openpgp
Message-ID	<Vng9thV-ERMDuIUawJIDLdf1BWWMl_fIBrSnEYJJ_aEVtw3VM-450tDZEZp0WXgzVokxcawyKPpcuRyqbdzDaL9NN5mJJogYPsQjiynVygI=@wussler.it>
Hi Simo,

thanks for chipping in.

> At this point the question should be about how to be maximally
> compatible if you think there will be cases where a PKCS#8 key should
> be interchanged with an openpgp key.

I am personally not convinced this interchangeability is even good.

> In all honesty I do not see what advantage there would be for OpenPGP
> to store the private keys as seeds for ML-DSA.

Well, this is the wire format. It's not how the implementation has to store it, and it's meant for communication.
I see no point in having an additional couple of KBs of data on the wire if we have the seed.

Once the SK is imported, the implementation can store the expanded format to increase performance.

> Frankly, at this point, it seems to me the most compatible format would
> be one where both the seed and the expanded keys are always stored as a
> private key, but allow the seed to be missing for those cases where it
> may not be available.

Given that some libraries don't like expanded formats, this makes a point for having the seed mandatory and the expanded optional (if we need both).

Therefore to me it looks like the opposite. I would prefer seed only, given I see importing into a hardware key a way more common operation than exporting.
A quick web search shows many results on how to import a key into a yubi or nitro key, but I didn't find anything on exporting (except some seriously advanced features, that won't get you the OpenPGP key but just the raw key material, and then you gotta convert it yourself)

Cheers,
Aron

--
Aron Wussler
Sent with ProtonMail, OpenPGP key 0x7E6761563EFE3930



On Wednesday, 26 February 2025 at 16:37, Simo Sorce <[email protected]> wrote:

> Hi Aron,
>
> A data point to indicate why the LAMPS choice is critical, while the
> OpenPGP one is less so.
>
> LAMPS defines the PKCS#8 format (for historical reasons) which is the
> binary representation used by the PKCS#11 standard (which is defined by
> OASIS instead of IETF) to export keys.
>
> If LAMPS does not support expanded keys it is a major issue, because
> the PKCS#11 TC would then have to retroactively define a different
> standard format to export those keys for those systems (can be software
> not necessarily hardware) that internally store only the expanded key
> and can't therefore emit a seed which is lost at generation time.
>
> Unfortunately NIST created this mess by indicating that the private key
> is the expanded key first (and still is the official "format" in all
> the FIPS standards). Later they added language that allows the seed to
> also be stored for later use and the LAMPS people ran with it proposing
> the use of a seed as the private key storage format, because you can
> always derive the expanded key from it.
>
> At this point the question should be about how to be maximally
> compatible if you think there will be cases where a PKCS#8 key should
> be interchanged with an openpgp key. As you noted these are generally
> private keys, and it is not common to move them around, so it is not a
> huge deal what the storage format is for most cases. That said using
> expanded key for storage will never be a problem (if LAMPS accept the
> fact of life that they have to deal with the expanded key in their
> format), while storing a seed could be a problem.
>
> In all honesty I do not see what advantage there would be for OpenPGP
> to store the private keys as seeds for ML-DSA. However there is one
> disadvantage in that you will always have to run the derive operation
> to obtain the expanded key, so potentially it means slowing down
> signing operations, unless the implementation has a good way to keep
> the expanded key in memory for repeat signatures.
>
> For ML-KEM there may be a size advantage if those private keys get
> exchanged in online protocols, but that is also not something PGP
> normally does, it is all pretty much "offline", and the size difference
> is generally insignificant as well for most cases, so that leaves only
> the (small) performance penalty of choosing seeds for storage.
>
> Frankly, at this point, it seems to me the most compatible format would
> be one where both the seed and the expanded keys are always stored as a
> private key, but allow the seed to be missing for those cases where it
> may not be available.
>
> Simo.
>
> On Wed, 2025-02-26 at 13:42 +0000, Aron Wussler wrote:
>
> > Hi Stephen,
> >
> > I personally think OpenPGP has a different usage and public than LAMPS, and while factoring their decisions does make a lot of sense, I would like to know if there is any strong usage requirement here.
> >
> > Many online tutorials explain how to import an existing OpenPGP key into an HSM, but haven't found much about exporting one, thus why I think that the "always being able to import" brings more value than "always being able to export".
> >
> > Said this, I might be living in my own bubble, know little about OpenPGP for software signing, and would like to explore the requirements on the list!
> >
> > Cheers,
> > Aron
> >
> > --
> > Aron Wussler
> > Sent with ProtonMail, OpenPGP key 0x7E6761563EFE3930
> >
> > On Wednesday, 26 February 2025 at 14:31, Stephen Farrell [email protected] wrote:
> >
> > > Hi Aron,
> >
> > > I've been watching the LAMPS discussion on this, but not reading
> > > it in detail (too many mails/options;-). Shouldn't we wait until
> > > LAMPS has reached a rough consensus on the topic before we make
> > > a change? We might or might not want to land in the same place,
> > > but it'd seem odd if we don't factor their conclusions into our
> > > discussion, and they don't yet seem to have reached a conclusion.
> > > (Or did I miss that?)
> >
> > > Thanks,
> > > S.
> >
> > > On 26/02/2025 11:51, Aron Wussler wrote:
> >
> > > > Hi everyone,
> >
> > > > At the interim meeting on February 10 we discussed the ML-KEM and ML-DSA secret key format, stating we'd prefer to keep the seed format even though LAMPS is reconsidering this choice because of HSM manufacturers.
> > > > We gave it another thought, and we'd like to collect more explicit consensus on this point, also considered Simo's thread on the list [1] that opened right after the interim.
> >
> > > > We would like to consider the following two options:
> >
> > > > ## Keeping the seed format only
> > > > This is the status quo in the specification.
> > > > - It makes it very hard to introduce a different SK format in the future, because we only use fixed length. It could be somehow inferred from the packet length, but it would be astonishingly hacky.
> > > > - Importing keys into HSMs will always be possible (no matter if expanded or seed, if tooling is available)
> > > > - Exporting keys from HSMs that support only expanded format will not produce a valid OpenPGP key (the key can't be rendered as the standard seed wire format, but they could be copied to a similar HSM)
> >
> > > > ## Allowing both seed and expanded format explicitly
> > > > Proposed text: https://github.com/openpgp-pqc/draft-openpgp-pqc/pull/171
> > > > - It makes both formats possible, preferring seed format
> > > > - Adds complexity and failure cases
> > > > - Importing keys into HSMs will sometimes fail (HSM supports only seed, but key is expanded)
> > > > - Exporting keys from HSMs will always result in a valid wire format
> > > > - Not all current crypto libraries accept the expanded format (one of the reasons why it's optional in the proposed spec)
> >
> > > > We have considered the option of adding a "version" or "type" byte that leaves the door open for a future standardization of another secret key format without doing it directly now, but I see only disadvantages in this:
> > > > - If we never use it, it's a useless byte and additional failure case (unknown value)
> > > > - If anyone ends up using it, it will bring all the complexity as defining two formats now, plus the chance of having little to no specification or guidance
> >
> > > > For reference, this is tracked in this issue: https://github.com/openpgp-pqc/draft-openpgp-pqc/issues/169
> >
> > > > Please provide feedback in the next two weeks (until the start of IETF 122 on Sat 15.03).
> >
> > > > Cheers,
> > > > Aron
> >
> > > > [1] https://mailarchive.ietf.org/arch/msg/openpgp/wborm6DvCotyZPzs-kPdyXPtoS0/
> >
> > > > --
> > > > Aron Wussler
> > > > Sent with ProtonMail, OpenPGP key 0x7E6761563EFE3930
> >
> > > > _______________________________________________
> > > > openpgp mailing list -- [email protected]
> > > > To unsubscribe send an email to [email protected]
> >
> > > _______________________________________________
> > > openpgp mailing list -- [email protected]
> > > To unsubscribe send an email to [email protected]
>
>
> --
> Simo Sorce
> Distinguished Engineer
> RHEL Crypto Team
> Red Hat, Inc
>
> _______________________________________________
> openpgp mailing list -- [email protected]
> To unsubscribe send an email to [email protected]

_______________________________________________
openpgp mailing list -- [email protected]
To unsubscribe send an email to [email protected]
signature.asc (application/pgp-signature, 343 B)