Adding new public key KEM API

[Simon Josefsson]

Detailed comments below, however first a big +1 for your effort here,
and to clarify that my opinions are not strong: I would prefer libgcrypt
to have sntrup761 under /any/ API than delaying adding support further
while trying to make the API perfect.  Post-quantum crypto has been
delayed for way too long already.

If it hasn't been mentioned already, I would give a +1 on supporting
Classic McEliece as well -- with support for McEliece, NTRU Prime and
Kyber we will have a good toolbox to work with.  I've looked at the
McEliece API needs, and they are the same as for NTRU Prime,
i.e. minimal API with no variable-length outputs.

NIIBE Yutaka <gniibe at fsij.org> writes:

> Hello,
>
> Simon Josefsson <simon at josefsson.org> wrote:
>> Is there any known algorithm that will make use of CONTEXT?  If not, I
>> suggest to drop the variable and when/if the need arise, add a separate
>> API for that use-case later on.
>
> When we consider ECDH KEM, Kyber, and NTRU Prime for Hybrid PQC, we
> don't need CONTEXT.
>
> My concern is for two cases.
>
> (1) Specifying the size of SHARED_SECRET
>
> Well, for this case, the size may be specified by encoding into ALGO,
> like GCRY_KEM_X25519_128 and GCRY_KEM_X25519_256.

I think a separate API with an explicit 'size_t shared_secret_length'
parameter would be a better interface than either of 1) 'void *context'
and casting of parameters, and 2) fixed-size ALGO identifiers.

> (2) KDF with domain seperation
>
> KDF under the KEM may want domain seperation.  (For the case of Hybrid
> PQC, this can be done in key combiner.)
>
> If I today considered OpenPGP support with ECDH KEM (alternative of
> RFC6637), I would need something like CONTEXT in the API to specify
> domain seperation with KDF.

I don't know the details here, so I can't tell if this is a generally
useful thing, although my preference would still be a separate API that
has a parameter with explicit type and documented purpose.

> If I supported a composite KEM of Hybrid PQC by the API, I would need
> CONTEXT, too.
>
> Well, this could be also solved by encoding information into ALGO, like
> GCRY_KEM_X25519_OPENPGP and GCRY_KEM_KEYBER768_PLUS_X25519_OPENPGP.

Hybrid modes are in my mind a new instance of a KEM that indeed warrant
a new identifier.

> In my not so humble opinion, it is not programmer's task to define this
> kind of API, but it is better for standardization process or academic to
> provide useful consensus for such an interface.
>
> Today, I found this paper:
>
> @misc{cryptoeprint:2023/272,
>       author = {Bertram Poettering and Simon Rastikian},
>       title = {A study of KEM generalizations},
>       howpublished = {Cryptology ePrint Archive, Paper 2023/272},
>       year = {2023},
>       doi = {10.1007/978-3-031-30731-7_3},
>       note = {\url{https://eprint.iacr.org/2023/272}},
>       url = {https://eprint.iacr.org/2023/272}
>
> And I wonder what SP800-227 (not yet vailable) will be.

Yeah, I think we need to take other research into account.  However I
would not give standardization bodies or researchers a carte blanche on
this -- then we end up with stuff like PKCS#11, DRBG-CTR or ASN.1 which
has awful APIs that are harmful to security.

/Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 255 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20231018/53e09589/attachment.sig>