Specification for Kyber in GnuPG

[Andrew Gallagher]

On 2 May 2024, at 19:10, Werner Koch <wk at gnupg.org> wrote:
> 
> The Brainpool curves are needed and not subject to discussion.

Is this a BSI requirement? Are there any other aspects of the list which are not subject to discussion?

> Adding
> different codepoints for the same algorithm (ECC-KEM + ML-KEM aka Kyber)
> is a major implementation hassle

Hassle for who though? Supporting both this proposal and the BSI/IETF PQC draft is a major implementation hassle. Supporting an arbitrary combination of algorithms that your underlying crypto library does not expose in its API is a major implementation hassle. Mapping a set of fixed code points to OIDs is a Friday afternoon job by comparison.

If you want other implementations to be interoperable with you, then you need to consider their concerns sometimes. (I’m thinking particularly about gopenpgp and hockeypuck here, although it applies to others also). I *want* to stay compatible with GnuPG, but it feels like every concern I raise is being dismissed out of hand. This is not how open standards are supposed to work.

> After all we are not TLS with its hunderds of codepoints for algorithms.
> Adding more codepoints to TLS is also the natural way - for TLS.

The OpenPGP asymmetric algorithms registry currently has 16 assigned code points out of 255, some of which have been reserved for years and never implemented. That’s less than 10% usage in over 30 years of PGP. Even if we’d always had separate code points for the various (recommended) sizes of RSA and the individual curves, we still wouldn't have filled up the unused block between code points 3 and 16. In the unlikely event we’re all still alive when the registry runs out, we can define new packet versions with a two byte algorithm ID area. This is a non issue.

I simply don’t understand how a difference of opinion over how to organise a numbering convention is sufficient justification for defining two completely separate standards that differ only in that numbering convention (and the knock-on effects thereof). The only explanation that makes sense is that it is a deliberate strategy to avoid having to discuss algorithm details with other implementations before shipping them in GnuPG. Which is very convenient for GnuPG, but not so convenient for the rest of us.

>> Once again I’ll beg you to please implement the Kousidis, Strenzke and
>> Wussler spec instead of making trivial changes to their assigned
> 
> The changes might sound trivial but I explained them above.  They come
> from an implementer with a specific and practical knowledge of OpenPGP
> protocol needs. The actual algorithm and cryptography has not changed
> because that is not my specific knowledge.  That is how OpenPGP has
> always been extended - let the crypto folks do the math and the coders
> the implementation.

Sorry, are you seriously claiming here that the authors of the IETF PQC draft, which include one of the principal developers of gopenpgp, do not have practical knowledge of OpenPGP protocol needs?

>> numbers in order to start a pointless and exhausting fight with the
>> IETF WG over ownership of the registry. If we need to allocate four
> 
> We can't wait another 9 years for a simple crypto enhancement. We need
> a new identifier NOW and need to get it used.

On this we agree, but I don’t believe that doing the same work twice helps us achieve it.

> After a discussion with
> the BSI we will temporary add a notification to Kyber keys created
> according to the current ML-KEM draft.  Just in case the NIST decides to
> do some final changes we can the detect keys created according to the
> current draft and sort them out.

Is this a GnuPG-specific proposal? It hasn’t been mentioned in any of the calls or emails I’ve been in with the authors of the IETF PQC draft, and the first author of that draft is a BSI employee.

I’m seriously worried now that the BSI appear to be funding and/or directing two separate instances of the same project. Is this a conscious decision by the BSI or just a failure of communication between departments?

A

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20240503/d705446f/attachment-0001.sig>