Keccak in libgcrypt

Jussi Kivilinna jussi.kivilinna at iki.fi
Sat Oct 24 15:26:13 CEST 2015


Hello,

On 2015-10-13 11:59, Gilles Van Assche wrote:
> Dear all,
> 
> As an everyday user of GPG and co-designer of Keccak, I am happy to see
> that you recently added Keccak/SHA-3 to libgcrypt's development branch. :-)
> 
> As I went through your code, I had some comments—please see below.

Thanks for looking it through and for the comments.

> 
> Anyway, please let me know if I can help.
> 
> Best wishes and happy coding,
> Gilles
> 
> 
> My comments are the following:
> 
> 1) The piece of code that you started from (i.e.,
> Keccak-readable-and-compact.c) is not meant to be fast. There are faster
> alternatives available in the Keccak Code Package. In particular, you
> can find implementations aiming for speed on 32-bit platforms (including
> ARM assembly code) and on 64-bit platforms. These implementations are
> organized in a way that only the code for the Keccak-f[1600] permutation
> and state input/output depends on the target platform. The rest is
> implemented using platform-independent code.

I've worked on rewrite of Keccak in libgcrypt. For starting poing I picked
'simple' and 'simple32bi' implementations from SUPERCOP package, as they 
seem to give reasonable performance and were easy to integrate. Refactored
code will also simplify adding new (assembly) implementations to libgcrypt.

> 
> 2) It would be great to add support for the SHAKE's. I understand that
> they are a new kind of functions (“extendable-output functions”), so
> requiring a different interface compared to traditional hash functions,
> but they can become really useful in the context of RSA (replacing the
> MGF) and ECDSA (or EdDSA).
> 
> 3) The type KECCAK_CONTEXT contains a buffer (byte
> buf[MD_BLOCK_MAX_BLOCKSIZE]) that is quite large. In fact, the sponge
> construction does not need such a buffer, namely, the input bytes can be
> XORed into the state as they arrive. The Keccak Code Package readily
> implements this.
> 

Ok, in the code, I've removed the use of the extra input buffer with Keccak.

-Jussi

> 
> _______________________________________________
> Gcrypt-devel mailing list
> Gcrypt-devel at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gcrypt-devel
> 



More information about the Gcrypt-devel mailing list