Adding new public key KEM API

[Falko Strenzke]

Am 24.10.23 um 08:25 schrieb NIIBE Yutaka:
> Werner Koch<wk at gnupg.org>  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.
But the point is, that what you refer to as static or run-time check is 
still error prone. As far as I can see, you did not yet specify what it 
is that the caller has to check the length against. But in any case this 
is another call to a macro or function which can contain an error, and 
thus, as Werner pointed out, incurs the risk of memory access errors.
>
> 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.

What exactly do you mean by "lower level" API? If this what we are 
currently discussing is a lower level API, then does this mean

- that it is not intended to be used by client applications but just 
internally by Libgcrypt? In that case I would refer to it as an internal 
API for clarity.
- that there will be another "higher level" API that is intended for 
client applications?

Turning the whole question around: what in your point of view speaks 
against including length parameters for each input/output byte array (on 
whatever level of API)?


- Falko

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

*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/20231024/46ff5015/attachment-0001.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/20231024/46ff5015/attachment-0001.bin>