<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">Am 15.09.23 um 10:08 schrieb Werner
Koch:<br>
</div>
<blockquote type="cite" cite="mid:87zg1nhn9j.fsf@jacob.g10code.de">
<pre class="moz-quote-pre" wrap="">On Thu, 14 Sep 2023 15:38, Falko Strenzke said:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">I don't understand what you mean exactly by "we may not even need
GCRY_MD_CSHAKE". Maybe it is with respect to how we implement it, in that case
see my comment below on reusing the SHAKE implementation.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
That we can use the GCRY_MD_SHAKE256 identifier also for cSHAKE. The
use of the control codes would modify SHAKE256 to cSHAKE.</pre>
</blockquote>
<p>It is correct that this approach is technically possible. But I
wonder if in that case there might result ambiguities somewhere in
applications if they cannot make the distinction between SHAKE
and cSHAKE via the algorithm identifier. Possibly there might be
the case where I want to allow only SHAKE and thus want to cause
the call to <code class="notranslate">_gcry_md_ctl() </code>for
the setting of the values of N and S to fail.</p>
<p>Another aspect is that the cSHAKE context is a bit larger than
the SHAKE context:</p>
<p><tt>typedef struct CSHAKE_CONTEXT_S<br>
{<br>
KECCAK_CONTEXT keccak_ctx;<br>
unsigned int rate_in_bytes;<br>
size_t written_bytes_n_s;<br>
int n_set;<br>
int s_set;<br>
} CSHAKE_CONTEXT;</tt><br>
</p>
<p>That is, however, just a few bytes and thus shouldn't matter much
in practice.</p>
<p>I think for this decision it matters if one gives priority to the
clarity of the algorithm modelling in the API and thus
distinguishes between SHAKE and cSHAKE or to not increasing the
number of hash algorithms. Given that the list of hash algorithms
is already long, I think the addition of two further algorithms
does not matter much. Also for the reason of clearer API would
clearly tend to model cSHAKE as a different algorithm than SHAKE
and thus would prefer to add the new identifiers.</p>
<p>- Falko<br>
</p>
<blockquote type="cite" cite="mid:87zg1nhn9j.fsf@jacob.g10code.de">
<pre class="moz-quote-pre" wrap="">
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">In my opinion we need to add GCRY_MD_CSHAKE128 and GCRY_MD_CSHAKE256, the two
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
As long as the resulting digest lengths are the same as the original SHAKE
versions, new identifier won't be needed. However, if cSHAKE and SHAKE
are used by a protocol in the same way, new identifiers are indeed
useful. What I mean is this:
switch (hash_algo) {
case GCRY_MD_SHAKE256: do_one_thing (); break,
case GCRY_MD_CSHAKE256: do_another_thing (); break,
....
}
Salam-Shalom,
Werner
</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.JP3nJm5T.ONosust0@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.VS9bQov9.Bw1GARPt@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>