Guido Bertoni^{3}, Joan Daemen^{1,2}, Michaël Peeters^{1}, Gilles Van Assche^{1} and Ronny Van Keer^{1}

^{1}STMicroelectronics - ^{2}Radboud University - ^{3}Security Pattern

Keccak follows an open design approach.

- Keccak comes with a
**clear design rationale**and has been extensively scrutinized by**third-party cryptanalysis**. For more details, we refer to the cryptanalysis page. - Unlike the previous hashing standards, the SHA-3, SHAKE, cSHAKE and other SHA-3-related functions are the outcome of an
**open competition**. - Keccak has a
**thick safety margin**. The Keccak sponge function should stand by its security claim even if the number of rounds is divided by two, as we did for Keyak and KangarooTwelve. - We showed that the Keccak-$f$ permutations have provable
**lower bounds on the weight of differential trails**. - The design of the permutations follows the
**Matryoshka principle**, where the security properties of the seven permutations are linked. The cryptanalysis of the smaller permutations, starting from the “toy” Keccak-$f[25]$, is meaningful to the larger permutations, and vice-versa. In particular, differential and linear trails in one Keccak-$f$ instance extend to symmetric trails in larger instances. - The sponge and duplex constructions used by Keccak are
**provably secure against generic attacks**. This covers also the joint use of multiple Keccak instances with different rate/capacity parameters. - Unlike SHA-1 and SHA-2, Keccak does not have the length-extension weakness, hence
**does not need the HMAC nested construction**. Instead, MAC computation can be performed by simply prepending the message with the key. - From the mode down to the round function, our design choices are fairly different from those in the SHA-1 and SHA-2 hash functions or in the Advanced Encryption Standard (AES). Keccak therefore
**provides diversity with respect to existing standards**.

Keccak inherits the flexibility of the sponge and duplex constructions. It can perform quasi all symmetric cryptographic functions, from hashing to pseudo-random number generation to authenticated encryption.

- As a sponge function, Keccak has
**arbitrary output length**. This allows to simplify modes of use where dedicated constructions would be needed for fixed-output-length hash functions. It can be natively used for, e.g., hashing, full domain hashing, randomized hashing, stream encryption, MAC computation. In addition, the arbitrary output length makes it suitable for tree hashing. - As a duplex object, Keccak can be used in
**clean and efficient modes**as a reseedable pseudo-random bit generator and for authenticated encryption. Efficiency of duplexing comes from the**absence of output transformation**. - Keccak has a
**simple security claim**. One can target a given security strength level by means of choosing the appropriate capacity, i.e., for a given capacity $c$, Keccak is claimed to stand any attack up to complexity $2^{c/2}$ (unless easier generically). This is similar to the approach of*security strength*used in NIST's SP 800-57. - The security claim is
**disentangled from the output length.**There is a minimum output length as a consequence of the chosen security strength level (i.e., to avoid generic birthday attacks), but it is not the other way around, namely, it is not the output length that determines the security strength level. For an illustration with the classical security requirements of hashing (i.e., collision and (second) preimage resistance), we refer to our interactive page. - The instances in SHA-3 and SHAKE make use of a
**single permutation**for all security strengths. This cuts down implementation costs compared to hash function families making use of two (or more) primitives, like the SHA-2 family. And with the same permutation, one can make**performance-security trade-offs**by way of choosing the suitable appropriate capacity-rate pair.

The Keccak-*f* permutations consist of the iteration of a simple round function, similar to a block cipher without a key schedule. The choice of operations is limited to bitwise XOR, AND and NOT and rotations. There is no need for table-lookups, arithmetic operations, or data-dependent rotations.

- Keccak excels in
**hardware performance**, with speed/area trade-offs, and outperforms SHA-2 by an order of magnitude. See for instance the works of Gürkaynak et al., Gaj et al., Latif et al., Kavun et al., Kaps et al. and Jungk presented at the Third SHA-3 Candidate Conference. - Keccak has
**overall good software performance**. It is on par with SHA-2 on modern processors and shines when used in a mode exploiting parallelism, such as ParallelHash (NIST SP 800-185) or KangarooTwelve. On constrained platforms, Keccak has moderate code size and RAM consumption requirements. - For modes involving a key, protecting the implementation against
**side-channel attacks**is wanted. The operations used in Keccak allow for**efficient countermeasures**against these attacks. Against cache-timing attacks, the most efficient implementations involve no table lookups. Against power analysis attacks and variants, countermeasures can take advantage of the quadratic round function.