Adding new public key KEM API

[Simon Josefsson]

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

> On Wed, 18 Oct 2023 11:00, Falko Strenzke said:
>
>> hash functions, MAC, etc. Or is there a specific reason to make the
>> type obscure specifically in this case?
>
> Yes, because they depend on the algorithm.  Opaque things should ise a
> void pointer to avoid unnecessary casting.  Remember that we are doing C
> and not C++.

I don't follow this -- I think the output variables should be 'unsigned
char *' or 'uint8_t *'.  Are there any KEM algorithm that won't have a
standardized byte-oriented output format?  If the output really was
opaque (which I think is not the intention), callers MUST NOT use them
even with a cast and libgcrypt should have some other function to
convert the 'void*' opaque pointer into a byte-stream for use by those
who want a byte-stream -- but I think that is not needed, and that all
the "opaque" outputs from KEM's will be treated as byte streams by all
callers.  Using 'void*' for things that always will be 'uint8_t*' loses
type safety features of C.

/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/9eb0754d/attachment.sig>