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

Aron Wussler <[email protected]> Wed, 26 Feb 2025 11:51:36 +0000

Newsgroups	gmane.ietf.openpgp
Message-ID	<vN75HSFXALBJQMd1A60IEhI_gqmw27cvjvVTK6APPoK-NjROf5a0KTPiRtUC3G04hrX_pb1Yzpu7n2R90yIVYbqJZpRPkkyxLbH6cy7tpjw=@wussler.it>

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]

signature.asc (application/pgp-signature, 343 B)