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

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
	 
	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 to [email protected] <mailto:[email protected]> 

		
		
		

		_______________________________________________
		openpgp mailing list -- [email protected] <mailto:[email protected]> 
		To unsubscribe send an email to [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]