KMAC / cSHAKE in Libgcrypt

Jussi Kivilinna jussi.kivilinna at iki.fi
Thu Aug 31 19:12:16 CEST 2023


Hello,

On 22.8.2023 14.49, Falko Strenzke wrote:
> We are currently working on the integration of PQC algorithms in Libgcrypt based on draft-wussler-openpgp-pqc <https://datatracker.ietf.org/doc/draft-wussler-openpgp-pqc/> and will also add KMAC to Libgcrypt since this algorithm is used for the key derivation inside the key combiner.
> 
> KMAC <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-185.pdf#page=16> is based on cSHAKE <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-185.pdf#page=13>, which is variant of SHAKE that requires a different final bit padding than SHAKE and is currently not implemented in Libgcrypt. cSHAKE is defined as
> 
> |cSHAKE(X, L, N, S): 1. If N = "" and S = "": return SHAKE256(X, L); 2. Else: return KECCAK[256](bytepad(encode_string(N) || encode_string(S), 168) || X || 00, L) |
> 
> In order to support the additional arguments N and S, I propose the following approach:
> 
>   *
> 
>     cSHAKE is added as an XOF message digest like SHAKE
> 
>   *
> 
>     For the purpose of providing the additional arguments N and S we add
> 
>     |typedef enum { GCRY_MD_ADDIN_CSHAKE_N = 1, GCRY_MD_ADDIN_CSHAKE_S = 2 } gcry_md_add_input_t; gcry_error_t gcry_md_set_add_input (gcry_md_hd_t *h, gcry_md_add_input_t addin_type, const void* v, size_t v_len) |
> 
>     In order to invoke cSHAKE with non-empty N and S parameters, after the call to |_gcry_md_open()|, two calls to |gcry_md_set_add_input()| have to be made to set N and S in that order. If data is added without having made these calls, then it will behave as normal SHAKE as required by the specification.
> 
> Does anyone have any thoughts on this?

I checked cSHAKE spec and think that interface is good way for passing these parameters. I first thought about having user to pass encoded N and S to gcry_md_write but that would mean that user needs to implement encode_string function from cSHAKE spec which would not work.

One additional thing to consider is the _gcry_md_hash_buffers_extract internal interface. There cSHAKE could take first two IO buffers as N and S strings and following buffers as actual data. This would be similar to how HMAC work through this interface, where first IO buffer is used as HMAC key and remaining buffers as data.

-Jussi

> 
> - Falko
> 
> -- 
> 
> *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>
> 
> 
> _______________________________________________
> Gcrypt-devel mailing list
> Gcrypt-devel at gnupg.org
> https://lists.gnupg.org/mailman/listinfo/gcrypt-devel



More information about the Gcrypt-devel mailing list