<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi Simon,<br>
</p>
<div class="moz-cite-prefix">Am 16.05.23 um 08:56 schrieb Simon
Josefsson via Gcrypt-devel:<br>
</div>
<blockquote type="cite" cite="mid:87y1lozrw7.fsf@kaka.sjd.se">
<pre class="moz-quote-pre" wrap="">Hi
Attached is a second version of the sntrup761 patch, this time using a
minimal API that would work for Kyber too (please confirm). Unless we
know complexity is required, I prefer to keep things minimal.
I've pushed it to:
<a class="moz-txt-link-freetext" href="https://gitlab.com/jas/libgcrypt/-/commits/jas/sntrup761v2">https://gitlab.com/jas/libgcrypt/-/commits/jas/sntrup761v2</a>
Below is the added API. Thoughts?
enum gcry_kem_algos
{
GCRY_KEM_SNTRUP761 = 761,
};
#define GCRY_KEM_SNTRUP761_SECRETKEY_SIZE 1763
#define GCRY_KEM_SNTRUP761_PUBLICKEY_SIZE 1158
#define GCRY_KEM_SNTRUP761_CIPHERTEXT_SIZE 1039
#define GCRY_KEM_SNTRUP761_SHAREDSECRET_SIZE 32
gcry_error_t gcry_kem_keypair (int algo,
void *pubkey,
void *seckey);
gcry_error_t gcry_kem_enc (int algo,
const void *pubkey,
void *ciphertext,
void *ss);
gcry_error_t gcry_kem_dec (int algo,
const void *ciphertext,
const void *seckey,
void *ss);</pre>
</blockquote>
<p>I think this is already going into the right direction. However,
I have some proposals:<br>
</p>
<p>1. I would prefer a more type safe API: distinct public and
private key objects instead of void pointers, i.e <tt>gcry_kem_public_key_t
</tt>and <tt>gcry_kem_private_key_t</tt>. From your proposed API
it does not become clear if pubkey and seckey are objects or just
byte arrays. Since instantiating a key from a byte array may
involve some precomputations (imagine for instance instantiating a
private key from a PRNG seed), for efficiency reasons it is in my
view necessary to have public and private key objects.<br>
</p>
<p>2. Also the enum should by typedef'd and used with its type in
the function signature.</p>
<p>3. There is no need to provide <tt>algo</tt> again in the
enc/dec functions. A key object will know it's algorithm.
(Probably this is due to key void pointers meant as byte arrays)<br>
</p>
<p>4. All input/output byte arrays should be typed as <tt>uint8_t*</tt>
and be passed in with their lengths. If without lengths, client
code will be prone to memory access errors.<br>
</p>
<p>5. Then we will also need extra functions for serialization and
deserialization of keys.</p>
<p>- Falko<br>
</p>
<blockquote type="cite" cite="mid:87y1lozrw7.fsf@kaka.sjd.se">
<pre class="moz-quote-pre" wrap="">
/Simon
</pre>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Gcrypt-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Gcrypt-devel@gnupg.org">Gcrypt-devel@gnupg.org</a>
<a class="moz-txt-link-freetext" href="https://lists.gnupg.org/mailman/listinfo/gcrypt-devel">https://lists.gnupg.org/mailman/listinfo/gcrypt-devel</a>
</pre>
</blockquote>
<div class="moz-signature">-- <br>
<!-- MTG AG HTML signature v.1.0 - Messen 2022, 2022-03-14 - Author: Andreas Cholet -->
<p style="line-height: 1.1;"><font face="Arial"><span
style="font-size: small; color: rgb(93, 93, 95);">
<strong>MTG AG</strong><br>
Dr. Falko Strenzke<br>
Executive System Architect<br>
<!--up to here--> </span></font></p>
<font face="Arial">
<p>
<span style="font-size: small; color: rgb(93, 93, 95);">
<span style="display:inline-block;width:4em">Phone: </span>+49
6151 8000 24<br>
<span style="display:inline-block;width:4em">E-Mail: </span><a class="moz-txt-link-abbreviated" href="mailto:falko.strenzke@mtg.de">falko.strenzke@mtg.de</a><br>
<span style="display:inline-block;width:4em">Web: </span><a
href="https://www.mtg.de" title="MTG AG Internet"
target="_blank">mtg.de</a><br>
<br>
<br>
<strong>MTG Exhibitions – See you in 2023</strong>
</span></p>
<font face="Arial">
<hr style="width:320px; text-align:left;margin-left:0; height:
0,1px">
<a
href="https://community.e-world-essen.com/institutions/allExhibitors?query=true&keywords=mtg"
title="Info E-world 2023" target="_blank" rel="“noopener"
noreferrer"="">
<img data-filename="Eworld.png"
src="cid:part1.ju43aU08.nCIimbid@mtg.de"
style="width:126px; margin-left: 6px"></a>
<span style="font-size: small; color: rgb(93, 93, 95);">
<a href="https://www.itsa365.de/de-de/companies/m/mtg-ag"
title="Info itsa365 2023" target="_blank" rel="“noopener"
noreferrer"="">
<img data-filename="itsa.png"
src="cid:part2.lxEU8BHR.t4mijFbL@mtg.de"
style="width:83px; margin-left: 60px"></a></span></font>
<span style="font-size: small; color: rgb(93, 93, 95);">
<!--a href="https://www.mtg.de/de/aktuelles/Hannover-Messe-2021-IT-Security-fuer-das-IoT/" title="Mehr Informationen" target="_blank"><strong>Mehr Informationen</strong></a -->
</span><br>
<br>
</font>
<p style="line-height: 1.2;"><font face="Arial">
<span style="font-size: x-small; color: rgb(93, 93, 95);">
MTG AG - Dolivostr. 11 - 64293 Darmstadt, Germany<br>
Commercial register: HRB 8901<br>
Register Court: Amtsgericht Darmstadt<br>
Management Board: Jürgen Ruf (CEO), Tamer Kemeröz<br>
Chairman of the Supervisory Board: Dr. Thomas Milde<br>
<br>
This email may contain confidential and/or privileged
information. If you are not the correct recipient or have
received this email in error,
<br>
please inform the sender immediately and delete this email.
Unauthorised copying or distribution of this email is not
permitted.<br>
<br>
Data protection information: <a
href="https://www.mtg.de/en/privacy-policy" title="MTG
Privacy policy" target="_blank">Privacy policy</a>
</span></font></p>
</div>
</body>
</html>