[openpgp] Re: Aligning KEM combiner in OpenPGP and LAMPS

[Simon Josefsson <[e-mail]>]

Aron Wussler <[e-mail]> writes:

> In order to have a single construction that works, I would propose the following concrete options:
>
> 1a.  KDF(mlkemSS || tradSS || CT || PK || Domain)
>       where CT = "tradCT" and PK = "tradPK" for LAMPS, and CT = "mlkemCT || tradCT" and PK = "mlkemPK || tradPK" for OpenPGP
>
> 1b.  KDF(mlkemSS || tradSS || CT || Domain)
>       where CT = "tradCT" and Domain = "tradPK || Domain" for LAMPS, and CT = "mlkemCT || tradCT" and Domain = "algID" for OpenPGP, and we drop PKs in OpenPGP (needed according to [3], and we already have "tradPK" in the ECDH KDF deriving tradSS)
>
> 2a. KDF(mlkemSS || tradSS || tradCT || tradPK || Domain)
>       where Domain is "Domain" for LAMPS, and "mlkemCT || mlkemPK || algId" for OpenPGP
>
> 2b. KDF(mlkemSS || tradSS || tradCT || Domain)
>       where Domain is "tradPK || Domain" for LAMPS, and "mlkemCT || algId" for OpenPGP, and we drop "mlkemPK" in OpenPGP (same as 1b, not needed according to [3])
>
> 2c. KDF(mlkemSS || tradSS || tradCT || tradPK || Domain)
>       where we drop mlkemCT and mlkemPK in the OpenPGP construction, fully aligning to LAMPS. Note that this would imply re-writing the security considerations, and while this has been proven safe for X-Wing, there are differing opinions on the security of this with ML-KEM 1024.

I believe it would be nice to pick a safe combiner that aligns with
requirements from as many PQKEM's we may want to plug into PGP as
possible.  Otherwise we will end up with a different combiner for
different hybrids eventually.  I have described Chempat [1] that uses
this construct:

H = SHA3-256
hybrid_pk = concat(receiver_pk_TKEM, receiver_pk_PQKEM)
hybrid_ct = concat(sender_ct_TKEM, sender_ct_PQKEM)
hybrid_ss = H(concat(ss_TKEM,
                     ss_PQKEM,
                     H(hybrid_ct),
                     H(hybrid_pk),
                     context))

Reviewing your options above, I believe the Chempat combiner has better
properties than all of the above.  In particular:

* Always include all shared secrets, ciphertext and public keys in what
  is KDF'ed, to bind all values to the resulting secret.

* Hash the potentially very long PQ ciphertext and/or public keys, for
  embedded applications that offload crypto to a separate co-processor
  and have limited storage for long data.

* Put the most trusted algorithm (X25519/X448) outputs earlier in the
  hash input string.

Still, I'm happy though that we have left the earlier broken design and
that we are moving in the right direction.

/Simon

[1] https://datatracker.ietf.org/doc/html/draft-josefsson-chempat-00