[openpgp] Re: Size of ML-DSA Secret key in draft-ietf-openpg p-pqc and other considerations

Hi Simo,

Thanks for the feedback! Part of it has been addressed in today's interim meeting, but am happy to relay here on the list.

1. Secret key for ML-DSA
The reasons why we decided to keep the seed only format after the PKCS#11 decision are:
- We consider the HSM private key export for further use in software an edge case for OpenPGP
- We want to reduce complexity and allow only one format
(- The seed format is smaller and always produces valid keys)

Note that having a mixed format would also cause problems with HSMs. You might not be able to import a key that is in expanded format into an HSM that stores it as a seed!
I personally believe importing a key into HSMs is a far more common operation. With a quick google search the articles referring to "having a hardware PGP key with backup" will refer to creating the key on a computer then importing it into a key [1,2]. Only few keys allow exporting, and they are rather advanced operations [3].

Note that the specification is only for the wire format, and transferring among identical tokens will still be possible, no matter the format we choose.

2. Code points
This was discussed at IETF 117, 118 and 119. We concluded that this could be done in a separate doc, adding a further codepoint for ML-DSA (or ML-KEM) as standalone when the WG feels ready for it.

3. Signature data digests
I honestly have seen that requirement, and am still wondering why the hell it is there. I don't understand it, and the "SHA-3 limits interoperability" reason sounds really weird to me, feels to me as "we have a machine in the basement that can break this hash". Happy to hear other reasons tho.

Said this, if for you this is a blocker for RHEL, I think we can revisit the hash binding requirement.

Cheers,
Aron

[1] https://support.yubico.com/hc/en-us/articles/360013790259-Using-Your-YubiKey-with-OpenPGP
[2] https://docs.nitrokey.com/nitrokeys/features/openpgp-card/openpgp-keygen-backup
[3] https://github.com/OpenSC/OpenSC/wiki/SmartCardHSM#using-key-backup-and-restore


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



On Monday, 10 February 2025 at 17:00, Simo Sorce <[email protected]> wrote:

> I have 3 comments for this draft:
>
> Secret key for ML-DSA
> =====================
>
> I see that in the PQC draft in table 7 the Secret key for ML-DSA is
> referred to as a fixed 32 bytes quantity. This means you are assuming
> that a seed is always available and used to store a private key.
>
> As already raised in LAMPS there is no assurance that hardware tokens
> will always be able to import/export a seed. In the PKCS#11 standard it
> is allowed to store a secret ML-DSA key with a private key value only
> (expanded as per FIPS203 definition of private key which is not the
> seed), as well as optionally provide a seed for import, as there is HW
> that may prefer or needs to store the expanded form.
>
> I am not sure it really matters how keys are stored when a PGP
> implementation uses a HW token, however if these definitions are used
> to construct an exchange format they should be amended to allow
> exchanging an expanded key when a seed is not available.
>
> If these definitions are never used to construct an exchange format for
> private keys then it should still be noted that how the secret key is
> stored depends on what is available (seed, vs expanded key, or both)
> and the size column could be eliminated or amended to list both options
> in terms of sizes.
>
>
> Code points
> ===========
>
> Considering the limitation of small tokens, it would be really useful
> if a non-hybrid option (for example ML-DSA-87 which is also the only
> algorithm allowed by CNSA 2.0 that fits PGP's scope) would be made
> available to reduce the amount of storage necessary on small smartcard-
> like devices.
>
>
> Signature data digests
> ======================
>
> Again to be able to comply with CNSA 2.0 guidelines it would be useful
> if SHA2-384 or SHA2-512 were allowed for signature data digests, given
> the guidelines do not allow SHA3 or SHAKE outside of the internal
> implementation of signature algorithms.
>
>
>
> Best,
> Simo.
>
> --
> 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]

-----BEGIN PGP SIGNATURE-----
Version: ProtonMail

wrsEARYKAG0FgmeqM+0JkH5nYVY+/jkwRRQAAAAAABwAIHNhbHRAbm90YXRp
b25zLm9wZW5wZ3Bqcy5vcmdA4kBuK9e2mTA+rb6ELyOYXks8raCGpUTf5ymX
3csDKxYhBIuVslFfa7tqthSdVX5nYVY+/jkwAAD+cQEAlQHA8KG8F12rhQDM
RQKT9jkXRyP/cIpikds8gjs2LBYA/21QyxR5gtRH3oeYUVvxUPo5pfbjG+3M
7bLsaILClUUA
=qRie
-----END PGP SIGNATURE-----