[openpgp] Size of ML-DSA Secret key in draft-ietf-openpgp-pqc and other considerations
Simo Sorce <[email protected]>
| Newsgroups | gmane.ietf.openpgp |
|---|---|
| Organization | Red Hat |
| Message-ID | <[email protected]> |
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]