Re: Post-quantum defaults

On 27 Apr 2026, at 08:14, Werner Koch via Gnupg-users <[email protected]> wrote:

The concrete format is based on a
paper and project by the BSI.

It’s more than a “paper and project”, it’s due to be published as an RFC any day now, and is widely implemented (by everyone else).

The important part from the paper and
prototype project the key-combiner algorithm. What we changed in
LibrePGP was to replace the way the PGP algorithm ids are assigned to
match how this has always been handled in PGP.

That’s not quite true, there are also differences in the fixedinfo and the order of inputs to the KEM combiner (see below) - but I find it fascinating that the algorithm numbering convention is the detail you highlight. Is it really that important?

The LibrePGP spec is also
easier to read for an implementer as it drops all unneeded theoretical
descriptions.

The other implementers didn’t seem to mind. :-)

p.s.

KEM Key Combiner

For comparison, the equivalent section in the forthcoming RFC can be found at https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-pqc#section-4.2.1 :

KEK = SHA3-256(
mlkemKeyShare || ecdhKeyShare ||
ecdhCipherText || ecdhPublicKey ||
algId || domSep || len(domSep)
)
return KEK

The value domSep is a constant set to the UTF-8 encoding of the string "OpenPGPCompositeKDFv1", that is:

domSep = 4F 70 65 6E 50 47 50 43 6F 6D 70 6F 73 69 74 65 4B 44 46 76 31

Here len(domSep) is the single octet with the value equal to the octet-length of domSep, that is, decimal 21.

Note however that the LibrePGP text below more closely resembles the first draft of the document:

https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-pqc-00#section-5.2.2

For the composite KEM schemes the following procedure MUST be used to
compute the KEK that wraps a session key. The construction is a one-
step key derivation function compliant to [SP800-56C] Section 4,
based on KMAC256 [SP800-185] and approved by [SP800-227]
Section 4.6.2. It is given by the following algorithm:

multiKeyCombine (eccKeyShare, eccCipherText,
mlkemKeyShare, mlkemCipherText,
fixedInfo, oBits)

Input:
eccKeyShare - the ECC key share encoded as an octet string
eccCipherText - the ECC ciphertext encoded as an octet string
mlkemKeyShare - the ML-KEM key share encoded as an octet string
mlkemCipherText - the ML-KEM ciphertext encoded as an octet string
fixedInfo - the fixed information octet string (see below)
oBits - the size of the output keying material in bits

Constants:
domSeparation - the UTF-8 encoding of the string
"OpenPGPCompositeKeyDerivationFunction"

Not “LibrePGP”? ;-)

counter - the four-octet big-endian value 0x00000001
customizationString - the UTF-8 encoding of the string "KDF"

eccData = eccKeyShare || eccCipherText
mlkemData = mlkemKeyShare || mlkemCipherText
encData = counter || eccData || mlkemData || fixedInfo

result = KMAC256 (domSeparation, encData, oBits, customizationString)

The fixedinfo is used to provide a binding between the KEK and the
communication parties. It is the concatenation of

* A one octet algorithm ID describing the symmetric algorithm used
for the bulk data in the in the SEIPD (packet 18) or the OCBED
(packet 20).

* The 32 octet version 5 fingerprint of the public key. Note that
the fingerprint covers the packet format and all other parameters
of the public key.

--
The pioneers of a warless world are the youth that
refuse military service. - A. Einstein
_______________________________________________
Gnupg-users mailing list
[email protected]
https://lists.gnupg.org/mailman/listinfo/gnupg-users

_______________________________________________
Gnupg-users mailing list
[email protected]
https://lists.gnupg.org/mailman/listinfo/gnupg-users