Adding new public key KEM API

Simon Josefsson simon at
Mon Nov 20 09:28:49 CET 2023

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.


Falko Strenzke <falko.strenzke at> writes:

> There is another point to consider for the design of a generic KEM API: the use of the public in the
> key derivation, which makes it necessary to pass the public key to the decapsulation function if one
> doesn't want to run the computation of the public key from the private key in the decapsulation
> function. 
> We are using using this now for instance in our OpenPGP PQC draft
> ( corrects the ECC-KEM function
> signature regarding that matter).
> - Falko
> Am 24.10.23 um 08:25 schrieb NIIBE Yutaka:
>  Werner Koch <wk at> wrote:
>  On Thu, 19 Oct 2023 16:37, NIIBE Yutaka said:
>  gcry_error_t gcry_kem_decap (int algo,
>                              const void *seckey,
>                              const void *ciphertext,
>                              void *shared_secret);
> I still don't feel comfortable without a size argument.
> Assumption here (for lower level API) is:
> 	It's caller side (user of libgcrypt) which does static
> 	compile-time check against ALGO and the length of each
> 	byte-array.
>         If not static, caller side can do run-time check, if needed,
>         before the call.
> Having a size argument would mean, 
> 	libgcrypt does run-time check of the length (for each call)
> I wonder if this kind of run-time check in libgcrypt is useful in lower
> level API.
> I could imagine having an API offering static compile-time check.  In
> this case, it would provide a macro something like gcry_kem_decap_check
> which has length arguments.  The ABI is gcry_kem_decap.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 255 bytes
Desc: not available
URL: <>

More information about the Gcrypt-devel mailing list