Updated PQC specification

[Werner Koch]

Hi!

Please find attached a draft version of the next LibrePGP draft
specification which describes the new KEM algorithms used for
quantum-resistant encryption.  Before a new draft is published some
minor things need to be fixed but it should nevertheless allow to
implement the same thing as we did in GnuPG master.

Note that here and in in GnuPG we use the term "Kyber" instead of
"ML-KEM" because that is easier to recognize.  [1]

As long as the crypto primitives are available adding that support is
straightforward because existing parser code may partly be re-used and
all variants are covered by just one algorithm id.

Support for quantum-resistant signature schemes is not not yet available
and far less urgent than encryption: The goal is to protect encrypted
data at rest (or being wiretapped).  Also new signature schemes need
more real world experience before they can be taken in use.

The migration plan to quantum-resistant encryption is to add new Kyber
subkeys so that implementation with support for them can start to use
them.  If at some point in the future a wide deployment as been achieved
an option (e.g. --require-pqc-encryption for gpg) can be used to force
encryption with a quantum-resistant algorithm (i.e. Kyber).

The scheme we use is as flexible as other algorithms in OpenPGP but an
implementaion is of course free to limit allowed algorithm combinations.
For example, only supporting the SHOULD combinations of algorithms is
perfectly fine.  In the current development stage and before the final
ML-KEM specification (FIPS203-final is expected this summer) having no
restrictions might be helpful, though.

In contrast to the original draft by wussler et al. we don't assign
separate code point to all algorithm combinations because that would
diverts from existing OpenPGP protocol behaviour.  In *PGP there is one
code point for RSA, one for DSA, one for Elgamal, one for ECDH, one for
ECDSA, one for EdDSA, and now one for Kyber.  They all have different
parameters: either direct specification of the parameters or an OID for
the curve parameters (which would be too large to include in all keys,
as it is allowed in X.509).  Thus it is natural for *PGP to do the same
for Kyber.

*PGP is a different protocol and has a different specification history
than TLS with its hundreds of codepoints for algorithm combinations.
Adding more codepoints to TLS is also the natural way - but for TLS.

Many thanks to Stavros Kousidis, Falko Strenzke, and Aron Wussler for
their draft on adding PQC to OpenPGP.  The algorithms used by LibgrePGP
are the same except for the fixed info.  I took the freedom to remove
the rationale parts which are not helpful for an implementer and was
thus able to make the description more concise.


Shalom-Salam,

   Werner


[1] In GnuPG's Git master as of today we use an algo name of "kyber" as
    a shortcut for ky768_bp256 (ML-KEM-768 + BrainpoolP256r1) and
    "kyber1024" as a shortcut for ky1024_bp384 (ML-KEM-768 +
    BrainpoolP256r1).
-- 
The pioneers of a warless world are the youth that
refuse military service.             - A. Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: draft-koch-librepgp-2024-05-06.txt.gz
Type: application/gzip
Size: 80682 bytes
Desc: not available
URL: <https://librepgp.org/pipermail/librepgp-discuss/attachments/20240506/58769643/attachment.gz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 247 bytes
Desc: not available
URL: <https://librepgp.org/pipermail/librepgp-discuss/attachments/20240506/58769643/attachment.sig>