This page is dedicated to the cryptographic sponge function family called Keccak, which has become the FIPS 202 (SHA-3) standard.

## Keccak in a nutshell

Keccak is a family of sponge functions. The *sponge function* is a generalization of the concept of cryptographic hash function with infinite output and can perform quasi all symmetric cryptographic functions, from hashing to pseudo-random number generation to authenticated encryption.

For a quick introduction, we propose a *pseudo-code* description of Keccak. The reference specification, analysis, reference and optimized code and test vectors for Keccak can be found in the file section.

As primitive used in the sponge construction, the Keccak instances call one of seven permutations named Keccak-*f*[*b*], with *b*=25, 50, 100, 200, 400, 800 or 1600. In the scope of the SHA-3 contest, we proposed the largest permutation, namely Keccak-*f*[1600], but smaller (or more “lightweight”) permutations can be used in constrained environments. Each permutation consists 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 has a very different design philosophy from its predecessor RadioGatún. This is detailed in our paper presented at Dagstuhl in 2009.

## Strengths of Keccak

### Flexibility

Keccak inherits the flexibility of the sponge and duplex constructions.

- 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 proposed for SHA-3 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.

### Design and security

- Keccak has a
**thick safety margin**. In [Keccak reference, Section 5.4], we estimate that the Keccak sponge function should stand by its security claim even if the number of rounds is almost divided by two (i.e., from 24 down to 13 in the case of Keccak-*f*[1600]). - Keccak was scrutinized by
**third-party cryptanalysis**. For more details, we refer to the cryptanalysis page. - 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**.

### Implementation

- 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 faster than SHA-2 on modern PCs and shines when used in a mode exploiting parallelism. On AMD™ Bulldozer™, 128-bit and 256-bit security hashing tops at 4.8 and 5.9 cycles/byte, respectively. On Intel™ Sandy Bridge™, the same functions reach 5.4 and 6.9 cycles/byte. 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.

## Latest news

### 31 May 2016 — New solutions to collision challenges

We congratulate **Jian Guo**^{1}, **Meicheng Liu**^{1,2}, **Ling Song**^{1,2,3} and **Kexin Qiao**^{2,3,1,4} for being the first ones to solve a 5-round collision challenge in the Keccak Crunchy Crypto Collision and Pre-image Contest!

They generated a collision for a Keccak variant with capacity 160 bits, calling the Keccak-f permutation with width 1600 and 5 rounds.

Remarkably, this breakthrough came only one month after two members of the same team, Jian and Meicheng, generated the first 3-round pre-images in our contest. [More details…]

- Cryptanalysis Taskforce, Temasek Laboratories @ Nanyang Technological University, Singapore
- State Key Laboratory of Information Security, Institute of Information Engineering, Chinese Academy of Sciences, China
- Data Assurance and Communication Security Research Center, Chinese Academy of Sciences, China
- University of Chinese Academy of Sciences, China

### 12 May 2016 — High-speed Keccak-FPH

When implemented on ASICs or on FPGAs, Keccak is significantly more efficient than other primitives with a similar security level, and allows efficient protections against side-channel attacks. Another area where Keccak's performance shines is on processors that exploit parallelism.

Recently, the NIST posted on the hash forum two draft special publications SP 800-XXX including proposals for customized SHAKE instances (Cshake), pseudo-random functions (KMAC), hash functions taking multiple strings as input (TupleHash) and a parallelized hash mode (Fast Parallel Hash, or **FPH**).

We implemented FPH in the Keccak Code Package and measured the following speeds for long messages:

Haswell | Skylake | |
---|---|---|

Keccak-FPH128 | 2.73 | 2.31 |

Keccak-FPH256 | 3.41 | 2.88 |

Keccak-FPH beats the speed line drawn by the legacy algorithms MD5 and SHA-1, usually considered fast.

Our implementation exploits the AVX-2 256-bit SIMD instruction set.

### 27 April 2016 — New solutions to pre-image challenges

We congratulate **Jian Guo** (Nanyang Technological University, Singapore) and **Meicheng Liu** (Nanyang Technological University, Singapore and State Key Laboratory of Information Security, Institute of Information Engineering, Chinese Academy of Sciences, China) for solving two 3-round pre-image challenges in the Keccak Crunchy Crypto Collision and Pre-image Contest!

Jian and Meicheng solved the 3-round pre-image challenges for widths 800 and 1600. There remains two others, i.e., those for widths 200 and 400, plus of course all the challenges with more rounds!!! [More details…]

### 16 March 2016 — Reorganized Keccak Code Package

The Keccak Code Package (or KCP) contains different free and open-source implementations of Keccak and closely related variants such as Ketje and Keyak.

We reorganized it to make it easier to use and to develop in or on it. More specifically, the main changes are the following.

- The functions related to the permutations Keccak-
*f*and Keccak-*p*are name-separated and can therefore coexist. Consequently, the different instances of Keccak, Ketje and Keyak can be compiled together. - The user can create a library
.`libkeccak.a`

- The user can easily select code optimized for a given platform.
- The parallel implementations can either exploit SIMD instructions or, when unvailable, rely on serial (or less parallel) implementations.

To sum up, the KCP contains:

- The FIPS 202 instances SHAKE128, SHAKE256, and SHA3-224 to SHA3-512.
- All the Keccak[
*r*,*c*] sponge functions and duplex objects with*r*+*c*=200, 400, 800 or 1600. - The Ketje and Keyak (version 2) authenticated encryption schemes, including
- Ketje Jr, Ketje Sr, River Keyak, Lake Keyak, Sea Keyak, Ocean Keyak and Lunar Keyak.
- Reference and optimized implementations of the Keccak-
*f*[*b*] and Keccak-*p*[*b*] permutations, including - compact implementations in C;
- generically optimized code in C for 32 or 64-bit platforms;
- assembly-optimized code for AVR8, ARMv6M, ARMv7M and ARMv7A.
- Paralellized implementations of the permutations, exploiting 128-bit and 256-bit SIMD instruction sets (SSE, AVX, AVX2).

### 19 August 2015 — Tweetable FIPS 202

Very compact (or *tweetable*) implementations of Keccak, written by D. J. Bernstein, Peter Schwabe and Gilles, are now available. In their most compact form, the 6 instances of SHA-3 and SHAKE can fit in just 9 tweets.

We published a series of compact implementations, from the more readable one to the most compact one.

- First, a readable and compact implementation of all the Keccak instances approved in the FIPS 202 standard, where we focused on clarity and on source-code compactness (excluding the comments), rather than on the performance. As much as possible, we used the same notation as in the specifications.
- Second, a more compact (but less readable) implementation, demonstrating that Keccak is conceptually simple.
- Third, a very compact implementation aimed at minimizing the number of tweets (i.e., lines of up to 140 characters each). With just 9 tweets, this means an average of 1.5 tweets per instance! As a comparison, SHA-512 alone takes about 27 tweets when extracted from TweetNaCl.

Dan presented the tweetable implementation at the rump session of Crypto 2015 [slides].

### 5 August 2015 — FIPS 202 is out: SHA-3 and Keccak beyond hashing

NIST officially released the FIPS 202 standard. Although it represents the target of the SHA-3 competition for a fresh hash function, the new standard provides more than just a successor to SHA-2: It comes as a toolbox with all the necessary ingredients for defining other uses of Keccak. About 2.5 years after the SHA-3 competition concluded, we recap on what the FIPS 202 standard contains.

The purpose of the FIPS 202 standard is twofold: It gives all the definitions needed to specify Keccak-based functions and it approves the use of six specific instances. The document is written bottom-up, starting with the bit-level operations in the Keccak-*p* permutations, a generalization of the Keccak-*f* permutations with a parameterized number of rounds, then moving to the sponge construction and, building on it, the Keccak family of sponge functions, and finally specifying the approved instances:

- four SHA-2 drop-in replacements with fixed output length SHA3-224 to SHA3-512, and
- two future-oriented
*extendable-output functions*SHAKE128 and SHAKE256.

**Extendable ouput functions**

The introduction of extendable-output functions (or XOFs, pronounced *zoff*) is a particularly nice feature of the standard. A XOF like SHAKE128 or SHAKE256 can be seen as a generalization of hash functions where the output length is not fixed but is potentially infinite. Concretely, XOFs can be used instead of complex constructions involving hash functions and counters such as MGF1. With RSA, this is of immediate benefit to full domain hashing, to RSA OAEP (Optimal Asymmetric Encryption Padding) and to RSA PSS (Probabilistic Signature Scheme). Other use cases are key derivation functions and stream ciphers.

Another important conceptual difference is that a XOF's security strength can be chosen (e.g., through Keccak's capacity value) and is not bound to its output length, as is traditionally the case for hash functions. This flexibility allows for better security-performance trade-offs. For instance, with a key derivation function, the length of the derived key material can greatly vary from one application to another, in a way that is in general not related to the required security strength.

**Future plans**

NIST expressed their intention to approve other modes of use of Keccak (or potentially other functions based on the Keccak-*p* permutations) as they are developed, by way of *special publications* in the NIST SP 800-*XX* series and referring to FIPS 202. At the SHA-3 2014 Workshop, NIST presented more details on the following topics:

- parallelizable hashing,
- message authentication codes (MACs) and key derivation functions,
- authenticated encryption,
- generic domain separation mechanisms on top of these.

**Code package**

The latest version of the Keccak Code Package is in line with the standard and contains test vectors for the six aforementioned instances.

## Contact Information

Email: `keccak`

*-at-*`noekeon`

*-dot-*`org`