Post-quantum defaults
Andrew Gallagher
andrewg at andrewg.com
Mon Apr 27 11:27:10 CEST 2026
Apologies for the triple post, I had trouble forcing apple mail to send
non-HTML mail. Thunderbird to the rescue! :-D
On 27 Apr 2026, at 08:14, Werner Koch via Gnupg-users
<gnupg-users at gnupg.org> 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
> Gnupg-users at gnupg.org
> https://lists.gnupg.org/mailman/listinfo/gnupg-users
> <openpgp-digital-signature.asc>
More information about the Gnupg-users
mailing list