<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi Simon,<br>
<br>
indeed, there is considerable overhead in our implementation of
the S-Expressions interface for the extraction of values and MPI
<-> byte array conversions even though each Kyber "token" is
merely an opaque byte array. However, we don't consider it our
call to divert from the existing API as we can't gauge the
implication of that for the client code, e.g. GnuPG. So we
basically consider this the maintainer's decision.<br>
</p>
<p>I looked through your API. It is indeed much simpler. I have the
following points, however:</p>
<p>1. I don't fully understand the design logic regarding the <tt>gcry_kem_hd_t</tt>.
I understand that it makes sense to use it for the encryption and
decryption to instantiate a particular key. But for the key
generation I don't per se see why it needs a handle. Is it
required for precomputations in the case of NTRU Prime? (or
anticipated that this is the case for other KEMs?)</p>
<p>2. "open" / "close" are in my opinion not the best names for the
function to create and destroy such a handle. These terms rather
suggest the handling of a file or a pipe. I know these terms are
also used in the hash API, but I think more appropriate names
would "create" / "destroy" or something similar. Maybe it makes
sense to make the move to a new terminology here.<br>
</p>
<p>3. While the previous two points are rather minor or even
cosmetic, this one is really important in my opinion: we need an
API that allows for derandomized key generation and encapsulation
to support KAT tests for all operations. The Kyber reference
implementation already supports such KAT tests. I would anyway
have raised the question here how to realize that. Signature
functions in libgcrypt already support a "random-override"
parameter, but so far I don't really understand how it works and
whether it would be suitable to use it for the KEM API as well.
Ideally, I think, the new API would allow to provide an RNG object
and to set it to a specific seed before any operation (possibly
via the KEM handle). However, it would probably be better if this
functionality is only supported by an internal test-API and not
available to normal clients. But I am not sure how to realize that
in the current design of libgcrypt.<br>
<br>
- Falko<br>
</p>
<div class="moz-cite-prefix">Am 15.05.23 um 16:20 schrieb Simon
Josefsson:<br>
</div>
<blockquote type="cite" cite="mid:87lehp1xsu.fsf@kaka.sjd.se">
<pre class="moz-quote-pre" wrap="">Hi
I noticed this thread just after submitting sntrup761 [1] patches.
My opinion is that libgcrypt's public-key API is a bad fit for KEM's: it
uses S-expressions and MPI data types. I believe the crypto world
rightly has moved away from those abstraction, towards byte-oriented
designs instead, for simplicity and safety. Compare gcry_ecc_mul_point
for X25519 and gcry_kdf_derive for KDF's. Could you implement Kyber as
a KEM using the API that I suggested? I think that would be
significantly simpler, and would help validate the KEM API as supporting
more than one KEM. I would strongly support having a KEM API that is
not using sexp/mpi, but I wouldn't object to a sexp/mpi API in addition
to it, for different use-cases.
/Simon
[1] <a class="moz-txt-link-freetext" href="https://gitlab.com/jas/libgcrypt/-/commits/jas/sntrup761">https://gitlab.com/jas/libgcrypt/-/commits/jas/sntrup761</a>
Falko Strenzke <a class="moz-txt-link-rfc2396E" href="mailto:falko.strenzke@mtg.de"><falko.strenzke@mtg.de></a> writes:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Hi Werner,
the only API change is the addition of the following interface function:
gcry_err_code_t
_gcry_pk_encap(gcry_sexp_t *r_ciph, gcry_sexp_t* r_shared_key, gcry_sexp_t s_pkey)
This also means that the public key spec needs to contain this additional function. For Kyber our public key spec currently looks as follows:
gcry_pk_spec_t _gcry_pubkey_spec_kyber = {
GCRY_PK_KYBER, {0, 1},
(GCRY_PK_USAGE_ENCAP), // TODOMTG: can the key usage "encryption" remain or do we need new KU "encap"?
"Kyber", kyber_names,
"p", "s", "a", "", "p", // elements of pub-key, sec-key, ciphertext, signature, key-grip
kyber_generate,
kyber_check_secret_key,
NULL, // encrypt
kyber_encap,
kyber_decrypt,
NULL, // sign,
NULL, // verify,
kyber_get_nbits,
run_selftests,
compute_keygrip
};
For the PKEs the encapsulation function would of course be NULL. Regarding the TODO on the key usage marked in the code above, this so far
doesn't seem to have any implications for us so the decision isn't urgent from my point of view.
- Falko
Am 30.03.23 um 15:43 schrieb Werner Koch:
On Wed, 29 Mar 2023 10:09, Falko Strenzke said:
While the integration of the signature algorithms is straightforward, the KEM
requires a new interface function, as the KEM encapsulation cannot be modelled
by a public-key encryption.
It would be good if we can discuss a proposed API early enough, so that
we can see how it fits into the design of Libgcrypt. Can you already
roughly describes the needs?
Salam-Shalom,
Werner
</pre>
</blockquote>
</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.pu9WGpPl.iuDgeu6T@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.cbWucXaA.5JdKBWI8@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>