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

Hi all,

can't we keep SHA3 as well, meaning we allow both a SHA3 and a SHA2 
variant? The user / policy can then decide what to use.

Best,
Johannes


On 11.02.2025 09:06, Kousidis, Stavros wrote:
> Hi all,
> 
> if CNSA 2.0 compliance is of utter importance and the key motivation 
> here, then one should explicitly alter the existing hash bindings.
> 
> That is, the table should state SHA-384 instead of SHA3-256, and 
> likewise SHA-512 instead of SHA3-512.
> 
> Compliance to CNSA 2.0 should than be explicitly claimed in the “Binding 
> hashes…” considerations section.
> 
> Being explicit here will avoid potential misunderstandings in the future.
> 
> @Aron: I left a corresponding comment in the PR.
> 
> Best
> Stavros
> 
> *Von:* Falko Strenzke <[email protected]>
> *Gesendet:* Dienstag, 11. Februar 2025 07:57
> *An:* [email protected]
> *Betreff:* [openpgp] Re: Size of ML-DSA Secret key in draft-ietf- 
> openpgp-pqc and other considerations
> 
> Hi Aron,
> 
> I agree with the proposed change. By no means the OpenPGP PQC RFC should 
> be a blocker for CNSA compliance.
> 
> Best regards,
> Falko
> 
> Am 10.02.25 um 22:23 schrieb Aron Wussler:
> 
>     Hi Simo,
> 
>         Yes this is the only "blocker" I have,
> 
>         We use PGP for signing packages and we really need a way to be CNSA 2.0
> 
>         compliant.
> 
>     Sounds like a fair point! I prepared a PR here:https://github.com/openpgp-pqc/draft-openpgp-pqc/pull/166 <https://github.com/openpgp-pqc/draft-openpgp-pqc/pull/166>
> 
>     If the list agrees with this, happy to get it merged :)
> 
>     Cheers,
> 
>     Aron
> 
>     --
> 
>     Aron Wussler
> 
>     Sent with ProtonMail, OpenPGP key 0x7E6761563EFE3930
> 
>     On Monday, 10 February 2025 at 21:33, Simo Sorce<[email protected]> <mailto:[email protected]> wrote:
> 
>         Hi Aron,
> 
>         On Mon, 2025-02-10 at 17:14 +0000, Aron Wussler wrote:
> 
>             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.
> 
>         It think this might come to bite in the future, but I do not have the
> 
>         energy to argue for it now. Once we'll have interop issue I'll let you
> 
>         guys deal with it :)
> 
>             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.
> 
>         Just to be clear the reason I am asking is that CNSA 2.0 "seems" to
> 
>         exclude hybrids (I know, not my choice, they also do not allow SLH-DSA
> 
>         which I would very much prefer for long term signatures... ).
> 
>         I think I can "work around" this by simply ignoring the spec and
> 
>         considering a signature valid even if the EdDSA part is unchecked, and
> 
>         live with that.
> 
>         For tokens that support only one key this is more challenging, but I
> 
>         guess one of the two keys will have to stay on disk and be less secure
> 
>         until a new spec that allows for "pure" algorithms is provided.
> 
>             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.
> 
>         Yes this is the only "blocker" I have,
> 
>         We use PGP for signing packages and we really need a way to be CNSA 2.0
> 
>         compliant.
> 
>         At this time it means ML-DSA-87 for signatures and either SHA-384 or
> 
>         SHA-512 for content hashes.
> 
>         I do not think the NSA can break SHA2 as they allow SHA3/SHAKE as
> 
>         internal implementations in the signature algorithms. I think this is
> 
>         more of a case of: "we have accelerators that can speed up SHA2 but not
> 
>         SHA3 and we want to keep using them for the time being to produce
> 
>         content hashes"
> 
>         This is my speculation, several of their positions are questionable,
> 
>         but I still need to be able to support their preferences as they are
> 
>         not broken (as far as we know).
> 
>         Best,
> 
>         Simo.
> 
>         --
> 
>         Simo Sorce
> 
>         Distinguished Engineer
> 
>         RHEL Crypto Team
> 
>         Red Hat, Inc
> 
>         _______________________________________________
> 
>         openpgp mailing list [email protected] <mailto:[email protected]>
> 
>         To unsubscribe send an email [email protected] <mailto:[email protected]>
> 
> 
> 
>         _______________________________________________
> 
>         openpgp mailing list [email protected] <mailto:[email protected]>
> 
>         To unsubscribe send an email [email protected] <mailto:[email protected]>
> 
> -- 
> 
> *MTG AG*
> Dr. Falko Strenzke
> 
> Phone: +49 6151 8000 24
> E-Mail: [email protected] <mailto:[email protected]>
> Web: mtg.de <https://www.mtg.de>
> 
> ------------------------------------------------------------------------
> 
> MTG AG - Dolivostr. 11 - 64293 Darmstadt, Germany
> Commercial register: HRB 8901
> Register Court: Amtsgericht Darmstadt
> Management Board: Jürgen Ruf (CEO), Tamer Kemeröz
> Chairman of the Supervisory Board: Dr. Thomas Milde
> 
> This email may contain confidential and/or privileged information. If 
> you are not the correct recipient or have received this email in error,
> please inform the sender immediately and delete this email.Unauthorised 
> copying or distribution of this email is not permitted.
> 
> Data protection information: Privacy policy <https://www.mtg.de/en/ 
> privacy-policy>
> 
> 
> _______________________________________________
> 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]