Re: [CFRG] [EXTERNAL] Re: Call for adoption: Hybrid KEM Combiners

[Watson Ladd <[e-mail]>]

On Tue, Feb 20, 2024 at 1:10 PM Mike Ounsworth
<[e-mail]> wrote:
>
> > We SHOULD NOT do this. We need to reduce the number of deployed algorithms.
>
>
>
> Right, but who gets to decide what is the correct set of reduced algorithms?
>
>
>
> On the one hand, we see the IETF people saying “If you don’t support X25519 then we can’t help you”. And on the other side, we have customers with very large PKIs who have yet to implement RSA-OAEP, never mind any form of elliptic curve. These customers want to leverage their existing crypto code for the hybrid and not implement new code on both sides of the hybrid.

I'm a little confused by what you mean by customers and code here, and
PKI is really more a signature issue than a KEM issue. If your
customers are implementing the algorithms themselves, they need to
write new code for the combiner and the new algorithm all of which is
security sensitive: adding in X25519 support is not that expensive on
top, especially given the large number of implementations available.

If you mean adapting the configuration/application code, all KEMs look
the same: you have an updated library, and use it. It doesn't matter
what's in it. I feel I'm missing something and some more details will
help.
>
>
>
> This is exactly the point. Who gets to play God and decide what that reduced set of algorithms is?

I'd flip that around: why should everyone get to increase the burden
on library developers by asking for yet another algorithm and letting
it proliferate. Can you make a case for including each of the
combinations you would like, bearing in mind the existence of each
other one?

Sincerely,
Watson Ladd