Adding new public key KEM API

Simon Josefsson simon at
Thu Oct 19 09:14:39 CEST 2023

Werner Koch via Gcrypt-devel <gcrypt-devel at> writes:

> On Wed, 18 Oct 2023 15:35, Simon Josefsson said:
>> callers.  Using 'void*' for things that always will be 'uint8_t*' loses
>> type safety features of C.
> A memory buffer has no defined type so you can't have type safety.

All KEM's I am aware of specify its outputs as byte vectors, not as
opaque memory buffers.  Same for symmetric algorithms like hashes and
encryption.  The only example to the contrary that I know of are some
asymmetric algorithms that provide outputs as multi-precision integers.

If we insist that outputs are opaque, there should be an API to convert
the opaque memory buffer into a byte-stream (which would most likely
just be an identity macro); otherwise this approach is inconsistent.  I
think treating the outputs as opaque does not give any significant
advantage though.

> I also tend to use unsigned char * for memory buffers (and char * for
> Nul-termnated string) but in Libgcrypt we have always used void* for
> data and keys.  Adding something else would be surprising.

Yes, consistency with existing APIs seems like a reasonable reason.
However I would trade that in to gain type checking.

-------------- 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