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

Aron Wussler <[email protected]> Mon, 10 Feb 2025 21:23:05 +0000

Newsgroups	gmane.ietf.openpgp
Message-ID	<rmWB0qyA-ZVBoC7QgnHl_tUg4HUBgTFIXytY03V3d9ihX3K7eSYAhYwoSJ-RpxCKhArQy4-OOpcuMJ6KsrKtoLtMB5nQ2NPuMAZlXV0pEko=@wussler.it>

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

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]> 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]
> 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)