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

On Tue, 2025-02-11 at 08:09 +0100, Falko Strenzke wrote:
> Hi Simo,
> 
> Am 10.02.25 um 21:33 schrieb Simo Sorce:
> > 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 :)
> If the expanded format turns out to be needed in the future, it could be 
> distinguished based on the length of the secret key material.

It could, but it will be danger territory to do that, it is quite
brittle, and there is a risk applications built today won't notice and
take the first 32 bytes of the expanded key and try to use them as the
seed. Of course this would be a bug but it is not a great place to be
in anyway.

> > 
> > > 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... ).
> In their FAQ 
> <https://media.defense.gov/2022/Sep/07/2003071836/-1/-1/0/CSI_CNSA_2.0_FAQ_.PDF>, 
> they say that they don't require hybrids, but don't exclude them.

I hope that will be the case. That said I already have another
classical signature to apply for historical/compatibility reasons
(RSA), so a hybrid signature is a net overhead for my use case, both in
having to manage yet another keypair, and in computation overhead in
the HSMs.

> > 
> > 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.
>  From how I read their FAQ, using the hybrids that are specified in the 
> draft should be fine with CNSA 2.0, even if both parts are checked.

Maybe, but my problem goes beyond that, see above.

> > 
> > 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.
> Hardware tokens might very well support both algorithms. As far as I can 
> see, at least Curve25519 is widely supported. I expect PQC-enabled 
> tokens to support both ML-* and *25519.

Yes it is possible, and hopefully we'll approve a pure ML-DSA code
point before long, it is just that the timings of CNSA 2.0 requiring PQ
signatures before the end of 2025 are creating pressure to establish
downstream conventions and create and distribute keys etc.. changing
later will be another hurdle.

> > 
> > > 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).
> 
> In the FAQ, NSA gives lack of interoperability as the reason for not 
> allowing SHA-3.

It makes little sense to claim lack of interoperability when you are
requesting net new signatures and also hinting that you do not care
about classic ones at all. But hey, whatever rocks their boat, I just
need to be compatible, not like the choice.

> 
> Best regards,
> Falko
> 
> > 
> > Best,
> > Simo.
> > 
> -- 
> 
> *MTG AG*
> Dr. Falko Strenzke
> 
> Phone: +49 6151 8000 24
> E-Mail: [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>
> 

-- 
Simo Sorce
Distinguished Engineer
RHEL Crypto Team
Red Hat, Inc

_______________________________________________
openpgp mailing list -- [email protected]
To unsubscribe send an email to [email protected]