[CFRG] Re: KEM combiners design team output

[Neil Madden <[e-mail]>]

> On 15 Jul 2024, at 10:49, Bas Westerbaan <[e-mail]> wrote:
> 
>> Regarding security properties, I am particularly interested in authenticated KEMs. Obviously most of the discussion around PQ KEMs is about IND-CCA, but almost all of my use-cases want data origin authentication. We don’t seem to have any good candidates for PQ AKEMs,
> 
> We do have PQ AKEMs that aren't that bad today: combine any PQ KEM and PQ signature scheme.

If you take say ML-KEM-512 and ML-DSA-44 for this (the weakest parameters), that is 768 + 2420 = 3188 bytes. When base64-encoded that already blows the 4kB cookie limit in browsers. I would say that is bad, compared to 32 bytes for an X25519 AKEM: a 2 orders of magnitude size increase is quite a hard sell! 

> That will do for HPKE. Signal requires a bit more than an HPKE AKEM: they would also like to have deniability, which you don't get when using a signature scheme instead of DH for authentication.

IMO repudiation should be the default (eg https://blog.cryptographyengineering.com/2020/11/16/ok-google-please-publish-your-dkim-secret-keys/) Let’s not entrench cryptographic schemes that cause further unintended consequences. 

Besides, signatures are just the wrong tool for the job for authentication: as evidenced by the amount of context you have to include in a signature to prevent misuse (timestamps, nonces, user info, session ids, transcript hashes, etc), precisely because signatures are equally valid for all parties at all times. Many protocols IMO would be immeasurably improved by de-Fiat-Shamir-ing them back into identification protocols (looking at you, FIDO). 

— Neil