The Keccak sponge function family

Guido Bertoni1, Joan Daemen1, Michaël Peeters2 and Gilles Van Assche1

1STMicroelectronics

2NXP Semiconductors

Pages

Documents

Notes

Software and other files

Figures

The figures above are available under the Creative Commons Attribution license. In short, they can be freely used, provided that attribution is properly done in the figure caption, either by linking to this webpage or by citing the article where the particular figure first appeared.

Links

Implementation aspects

This page lists implementation aspects of Keccak.

K. Ideguchi, T. Owada and H. Yoshida, A Study on RAM Requirements of Various SHA-3 Candidates on Low-cost 8-bit CPUs, comment on the NIST Hash Competition, 2009

In this document, the authors assume that the message block is counted towards the memory usage of the application. It is a valid assumption in several cases. However, there are also applications for which the message is formatted on the fly or does not need to be kept after being hashed. There, constructions such as sponge functions or similar (e.g., CubeHash, LUX) can directly XOR the message block into the state, relieving the application from dedicating a memory area for it. This optimization also applies where the hashing API is composed of functions such as Init, Update and Final. In general a message queue must be allocated, which can be avoided for sponge functions or similar.

About Keccak specifically, the designer of an application on a memory-constrained device may also opt for a smaller state size by using an alternate set of parameters, such as Keccak[r=288,c=512], which uses 100 bytes of RAM. And if 256 bits of capacity are enough for such an application, Keccak[r=144,c=256] uses only 50 bytes.

G. Bertoni, J. Daemen, M. Peeters and G Van Assche, Note on side-channel attacks and their countermeasures, May 2000

In this note we discuss side channel attacks and countermeasures that are particularly relevant when SHA-3 works in a keyed mode (e.g., HMAC) on devices to which adversaries may have physical access such as smart cards. We come to the conclusion that in general protecting ARX algorithms against side-channel attacks is expensive while this is much cheaper for algorithms that can be implemented with bitwise Boolean operations and (cyclic) shifts only.

G. Bertoni, J. Daemen, M. Peeters and G Van Assche Building power analysis resistant implementations of Keccak, Second SHA-3 Candidate Conference, August 23-24, 2010

In this paper we report on Keccak implementations, both soft- and hardware, that offer a high level of resistance against power analysis by using the technique of masking (secret sharing) at relatively low cost.

Software performance figures can be found on a dedicated software performance figures page and hardware implementation results on hardware implementation results page.