[PATCH gpgme] Add RFC 9980 post-quantum public-key algorithms

[Werner Koch]

Hello!

thanks for working with GPGME and for your patch.

I see two problems with your implementation:

1. The name of the identifiers do not match those used by GnuPG.  For
   example GPGME_PK_MLKEM768_X25519 vs PUBKEY_ALGO_MLK768_25519 in
   GnuPG.  This is of course easy to fix by using GPGME_PK_MLK768_25519.

   Also for "ML-KEM-768+X25519" vs. "mlk768".  For the new Brainpool
   support we use "mlk768_bp384".

2. A combinatorial explosion due to the way RFC-9850 work.  In gpgme we
   should avoid this.  For example there is an internal mapping

     int
     _gpgme_map_pk_algo (int algo, gpgme_protocol_t protocol)
     {
       if (protocol == GPGME_PROTOCOL_OPENPGP)
         {
           switch (algo)
             {
             case 1: case 2: case 3: case 8: case 16: case 17: break;
             case 18: algo = GPGME_PK_ECDH; break;
             case 19: algo = GPGME_PK_ECDSA; break;
             case 20: break;
             case 22: algo = GPGME_PK_EDDSA; break;
             default: algo = 0; break; /* Unknown.  */
             }
         }

   used to map the OpenPGP algorithm numbers to to those used by
   Libgcrypt.  This is actually straighforward but in Libgcrypt we do
   not have separate Ids for each ML-KEM/ECDH combination.  Instead we
   use one identifier (8 for ML-KEM with ECDH) and use the length and
   curve parameter to specify the details.  This reflects what we have
   always done with RSA, Elgamal, and ECC: A base algorithm and
   parameters for the details.

   For the 9980 algos I would suggest to map all ML-KEM algos to a new
   GPGME_PK_MLKEM which will match a new GCRY_PK_MLKEM Peseudo ID with
   value 331.  For the ML-DSA algos a GPGME_PK_MLDSA would match the
   Libgcrypt GCRY_PK_MLDSA identifier (value 332).  Using these new
   identifiers we can keep the IETF way of combining the algos apart
   from your and the BSIs original key combiner (as specified by
   LibrePGP).  They are already denoted by GPGME_PK_KYBER and
   (eventually) GPGME_PK_DILITHIUM.

   GPGME applications already need to take the curve (and length)
   parameter in account and thus can decide whether the 9980 or the
   LibrePGP key combiner is used.


BTW, GnuPG 2.5.23 was released yesterday with support for 9980 inclduing
Brainpool and NIST versions of ML-KEM.



Salam-Shalom,

   Werner


-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 284 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20260923/2e9947a5/attachment-0001.sig>