KMAC / cSHAKE in Libgcrypt

[Falko Strenzke]

Am 15.09.23 um 10:08 schrieb Werner Koch:
> On Thu, 14 Sep 2023 15:38, Falko Strenzke said:
>
>> 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.
> That we can use the GCRY_MD_SHAKE256 identifier also for cSHAKE.  The
> use of the control codes would modify SHAKE256 to cSHAKE.

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 |_gcry_md_ctl() |for 
the setting of the values of N and S to fail.

Another aspect is that the cSHAKE context is a bit larger than the SHAKE 
context:

typedef struct CSHAKE_CONTEXT_S
{
     KECCAK_CONTEXT keccak_ctx;
     unsigned int rate_in_bytes;
     size_t written_bytes_n_s;
     int n_set;
     int s_set;
} CSHAKE_CONTEXT;

That is, however, just a few bytes and thus shouldn't matter much in 
practice.

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.

- Falko

>
>> In my opinion we need to add GCRY_MD_CSHAKE128 and  GCRY_MD_CSHAKE256, the two
> 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
>
-- 

*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 Exhibitions – See you in 2023*

------------------------------------------------------------------------
<https://community.e-world-essen.com/institutions/allExhibitors?query=true&keywords=mtg> 
<https://www.itsa365.de/de-de/companies/m/mtg-ag>

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/20230918/5b6d4d91/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: N014Z0Ln78zSIiSi.png
Type: image/png
Size: 5256 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20230918/5b6d4d91/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: j3EDMJkPI74X3LOQ.png
Type: image/png
Size: 4906 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20230918/5b6d4d91/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4764 bytes
Desc: Kryptografische S/MIME-Signatur
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20230918/5b6d4d91/attachment-0001.bin>