Adding new public key KEM API

[Simon Josefsson]

Werner Koch via Gcrypt-devel <gcrypt-devel at gnupg.org> 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.

/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/20231019/bde740d5/attachment.sig>