Adding new public key KEM API

[Falko Strenzke]

Sure, it is dependent on the algorithm. So it is the case also in the 
case of gcry_mac_handle which then internally uses a union for the 
different algorithm types. gcry_md_handle uses different approach by 
adding space at the end of the struct depending on the algorithm.

So my question would be why we don't use one of these existing 
approaches for APIs as well for the KEM API.

I think the union approach used in the case of the MAC API is much more 
transparent then the approach taken for the hash API and would be my 
recommendation for the KEM API. Overly large reservations in the struct 
for specific KEM algorithms can be prevented by the algorithm specific 
code allocating heap memory for them during the open() call.

- Falko

Am 18.10.23 um 11:21 schrieb Werner Koch:
> 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++.
>
>
> Salam-Shalom,
>
>     Werner
>
-- 

*MTG AG*
Dr. Falko Strenzke
Executive System Architect

Phone: +49 6151 8000 24
E-Mail: falko.strenzke at mtg.de
Web: mtg.de <https://www.mtg.de>


------------------------------------------------------------------------

MTG AG - Dolivostr. 11 - 64293 Darmstadt, Germany
Commercial register: HRB 8901
Register Court: Amtsgericht Darmstadt
Management Board: Jürgen Ruf (CEO), Tamer Kemeröz
Chairman of the Supervisory Board: Dr. Thomas Milde

This email may contain confidential and/or privileged information. If 
you are not the correct recipient or have received this email in error,
please inform the sender immediately and delete this email. Unauthorised 
copying or distribution of this email is not permitted.

Data protection information: Privacy policy 
<https://www.mtg.de/en/privacy-policy>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20231018/cd356b92/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4813 bytes
Desc: Kryptografische S/MIME-Signatur
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20231018/cd356b92/attachment.bin>