Adding new public key KEM API

[Daniel Kahn Gillmor]

On Mon 2023-11-20 09:28:49 +0100, Simon Josefsson via Gcrypt-devel wrote:
> One common solution to that problem is to include the public key in the
> data array holding the private key.  The SNTRUP761 implementations I've
> worked with does that by default, and I thought it was a fairly common
> design pattern.

This doesn't seem like an unreasonable approach, but it also requires a
well-documented serialization (and deserialization) convention for the
public key material when aggregated with the private key.  That might be
as simple as mere concatenation of already well-defined, fixed-length
byte arrays for public and private key material.  but it's not
necessarily the case, depending on the KEM.

That said, an abstract KEM API that only works for KEMs that do have
such well-defined serialization and aggregation conventions sounds like
it hits a sweet spot to me:

 - The API surface is minimal

 - Most callers don't want to have to fiddle with thinking about sizes
   or relative strengths of parameterized algorithm choices anyway, and
   would prefer to treat the components as bytestrings in the first
   place.
   
 - And it aggressively selects for/prefers well-defined KEM abstractions
   in the first place.

A simple, narrow API that makes it convenient to use reasonable
algorithms is a net win, even (especially?) if it discourages users of
the library from trying to adopt other more complex algorithms that
require something more ungainly or idiosyncratic.

   --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20231121/809f8e0e/attachment.sig>