|Designers||Guido Bertoni, Joan Daemen, Michaël Peeters, and Gilles Van Assche.|
|Certification||FIPS PUB 180-4|
|Speed||12.5 cpb on Core 2 [r=1024, c=576].|
SHA-3, a subset of the cryptographic primitive family Keccak (//, or //), is a cryptographic hash function designed by Guido Bertoni, Joan Daemen, Michaël Peeters, and Gilles Van Assche, building upon RadioGatún. The SHA-3 standard was released by NIST on August 5, 2015.
On October 2, 2012, Keccak was selected as the winner of the NIST hash function competition. SHA-3 is not meant to replace SHA-2, as no significant attack on SHA-2 has been demonstrated. Because of the successful attacks on MD5 and SHA-0 and theoretical attacks on SHA-1, NIST perceived a need for an alternative, dissimilar cryptographic hash, which became SHA-3.
The Keccak algorithm (which NIST say is pronounced "catch-ack" but the Dr. Dobb's Journal say is pronounced "ket-chak") is the work of Guido Bertoni, Joan Daemen (who also co-designed the Rijndael cipher with Vincent Rijmen), Michael Peters, and Gilles Van Assche.
On August 5, 2015 NIST announced that SHA-3 had become a hashing standard.
SHA-3 uses the sponge construction, in which message blocks are XORed into a subset of the state, which is then transformed as a whole. In the version used in SHA-3, the state consists of a 5 × 5 array of 64-bit words, 1600 bits total. The authors claim 12.5 cycles per byte on an Intel Core 2 CPU. However, in hardware implementations, it is notably faster than all other finalists.
Keccak's authors have proposed additional, not-yet-standardized uses for the function, including an authenticated encryption system and a "tree" hash for faster hashing on certain architectures. Keccak is also defined for smaller power-of-2 word sizes w down to 1 bit (25 bits total state). Small state sizes can be used to test cryptanalytic attacks, and intermediate state sizes (from w = 8, 200 bits, to w = 32, 800 bits) can be used in practical, lightweight applications.
The block permutation
This is defined for any power-of-two word size, w = 2ℓ bits. The main SHA-3 submission uses 64-bit words, ℓ = 6.
The state can be considered to be a 5 × 5 × w array of bits. Let a[i][j][k] be bit (5i + j) × w + k of the input, using a little-endian bit numbering convention. Index arithmetic is performed modulo 5 for the first two dimensions and modulo w for the third.
The basic block permutation function consists of 12 + 2ℓ iterations of five sub-rounds, each individually very simple:
- Compute the parity of each of the 5w (320, when w = 64) 5-bit columns, and exclusive-or that into two nearby columns in a regular pattern. To be precise, a[i][j][k] ← a[i][j][k] ⊕ parity(a[i][j−1][k]) ⊕ parity(a[i][j+1][k−1])
- Bitwise rotate each of the 25 words by a different triangular number 0, 1, 3, 6, 10, 15, .... To be precise, a is not rotated, and for all 0 ≤ t < 24, a[i][j][k] ← a[i][j][k−(t+1)(t+2)/2], where .
- Permute the 25 words in a fixed pattern. a[j][2i+3j] ← a[i][j]
- Bitwise combine along rows, using a ← a ⊕ (¬b & c). To be precise, a[i][j][k] ← a[i][j][k] ⊕ ¬a[i][j+1][k] & a[i][j+2][k]. This is the only non-linear operation in SHA-3.
- Exclusive-or a round constant into one word of the state. To be precise, in round n, for 0 ≤ m ≤ ℓ, a[2m−1] is exclusive-ORed with bit m + 7n of a degree-8 LFSR sequence. This breaks the symmetry that is preserved by the other sub-rounds.
Hashing variable-length messages
SHA-3 uses the "sponge construction", where input is "absorbed" into the hash state at a given rate, then an output hash is "squeezed" from it at the same rate.
To absorb r bits of data, the data is XORed into the leading bits of the state, and the block permutation is applied. To squeeze, the first r bits of the state are produced as output, and the block permutation is applied if additional output is desired.
Central to this is the "capacity" of the hash function, which is the c = 25w − r state bits that are not touched by input or output. This can be adjusted based on security requirements. The maximum security level is half the capacity.
To ensure the message can be evenly divided into r-bit blocks, padding is required. Keccak uses the pattern 10*1: a 1 bit, zero or more 0 bits (maximum r − 1), and a final 1 bit. The final 1 bit is required because the sponge construction security proof requires that the rate is encoded in the final block ("multi rate padding").
To compute a hash, initialize the state to 0, pad the input, and break it into r-bit pieces. Absorb the input into the state; that is, for each piece, XOR it into the state and then apply the block permutation.
After the final block permutation, the desired n number of bits is squeezed. For the SHA3 instances, r is always greater than n, thus there is never a need for additional block permutations in the squeezing phase. The leading n bits of the state are the desired hash. However, arbitrary output length may be useful in applications such as optimal asymmetric encryption padding.
Although not part of the SHA-3 standard, smaller variants of the block permutation can be used, for hash output sizes up to half their state size, if the rate r is limited appropriately. For example, a 256-bit hash can be computed using 25 32-bit words if r = 800 − 2 × 256 = 288 (36 bytes per iteration).
The NIST standard defines the following instances.
Keccak[capacity](M, d) is defined as the sponge construction using Keccak-f[1600, capacity], message M and output length d.
|SHAKE128(M, d)||Keccak(M||1111, d)|
|SHAKE256(M, d)||Keccak(M||1111, d)|
The SHA3 instances are the drop-in replacements for SHA2, with identical security claims. SHAKE instances are so called XOF's, Extendible Output Functions. For example SHAKE128(M, 256) can be used as a hash function with 128 bit overall security.
Note that all instances append some bits to the message. Since 10*1 padding always adds at least two bits, in byte aligned libraries we always have six unused zero bits. Therefore these appended extra bits never make the padded message longer.
- The number of rounds was increased from 12 + ℓ to 12 + 2ℓ to be more conservative about security.
- The message padding was changed from a more complex scheme to the simple 10*1 pattern described above.
- The rate r was increased to the security limit, rather than rounding down to the nearest power of 2.
NIST announcement controversy
In February 2013 at the RSA Conference, and then in August 2013 at CHES, NIST announced they would select different values for the capacity, i.e. the security parameter, for the SHA-3 standard, compared to the submission. The changes caused some turmoil.
In September 2013, Daniel J. Bernstein suggested on the NIST hash-forum mailing list to strengthen the security to the 576-bit capacity that was originally proposed as the default Keccak. In late September, the Keccak team responded by stating that they proposed 128-bit security by setting c = 256 as an option already in their SHA-3 proposal. However, in the light of the uproar in the cryptographic community, they proposed raising the capacity to 512 bits for all instances.
In early October 2013, Bruce Schneier criticized NIST's decision on the basis of its possible detrimental effects on the acceptance of the algorithm, saying
There is too much mistrust in the air. NIST risks publishing an algorithm that no one will trust and no one (except those forced) will use.
Paul Crowley, a senior developer at an independent software development company, expressed his support of the decision, saying that Keccak is supposed to be tunable and there is no reason for different security levels within one primitive. He also added:
Yes, it’s a bit of a shame for the competition that they demanded a certain security level for entrants, then went to publish a standard with a different one. But there’s nothing that can be done to fix that now, except re-opening the competition. Demanding that they stick to their mistake doesn’t improve things for anyone.
There was also some confusion that internal changes were made to Keccak. The Keccak team clarified this, stating that NIST's proposal for SHA-3 is a subset of the Keccak family, for which one can generate test vectors using their reference code submitted to the contest, and that this proposal was the result of a series of discussions between them and the NIST hash team. Also, Bruce Schneier corrected his earlier statement, saying
I misspoke when I wrote that NIST made "internal changes" to the algorithm. That was sloppy of me. The Keccak permutation remains unchanged. What NIST proposed was reducing the hash function's capacity in the name of performance. One of Keccak's nice features is that it's highly tunable.
In November 2013, in the light of the uproar in the cryptographic community, John Kelsey of NIST proposed to go back to the original c = 2n proposal for all SHA-2 drop-in replacement instances. These changes were confirmed in the April 2014 draft. This proposal was implemented in the final release standard.
Examples of SHA-3 variants
SHA3-224("") 6b4e03423667dbb73b6e15454f0eb1abd4597f9a1b078e3f5b5a6bc7 SHA3-256("") a7ffc6f8bf1ed76651c14756a061d662f580ff4de43b49fa82d80a4b80f8434a SHA3-384("") 0c63a75b845e4f7d01107d852e4c2485c51a50aaaa94fc61995e71bbee983a2ac3713831264adb47fb6bd1e058d5f004 SHA3-512("") a69f73cca23a9ac5c8b567dc185a756e97c982164fe25859e0d1dcc1475c80a615b2123af1f5f94c11e3e9402c3ac558f500199d95b6d3e301758586281dcd26 SHAKE128("", 256) 7f9c2ba4e88f827d616045507605853ed73b8093f6efbc88eb1a6eacfa66ef26 SHAKE256("", 512) 46b9dd2b0ba88d13233b3feb743eeb243fcd52ea62b81b82b50c27646ed5762fd75dc4ddd8c0f200cb05019d67b592f6fc821c49479ab48640292eacb3b7c4be
Changing a single bit results in all the bits in the output to change with 50% probability, demonstrating an avalanche effect:
SHAKE128("The quick brown fox jumps over the lazy dog", 256) f4202e3c5852f9182a0430fd8144f0a74b95e7417ecae17db0f8cfeed0e3e66e SHAKE128("The quick brown fox jumps over the lazy dof", 256) 853f4538be0db9621a6cea659a06c1107b1f83f02b13d18297bd39d7411cf10c
Comparison of SHA functions
In the table below, internal state means the number of bits that are carried over to the next block.
|Algorithm and variant||Output size
|Internal state size
|Max message size
|MD5 (as reference)||128||128
(4 × 32)
|512||264 − 1||64||And, Xor, Rot,
Add (mod 232),
(5 × 32)
|512||264 − 1||80||And, Xor, Rot,
Add (mod 232),
(5 × 32)
|512||264 − 1||80||<80
(theoretical attack in 261 operations)
(8 × 32)
|512||264 − 1||64||And, Xor, Rot,
Add (mod 232),
(8 × 64)
|1024||2128 − 1||80||And, Xor, Rot,
Add (mod 264),
(5 × 5 × 64)
|Unlimited||24||And, Xor, Rot,
- "NIST Selects Winner of Secure Hash Algorithm (SHA-3) Competition". NIST. 2012-10-02. Retrieved 2012-10-02.
- Guido Bertoni, Joan Daemen, Michaël Peeters and Gilles Van Assche. "The Keccak sponge function family: Specifications summary". Retrieved 2011-05-11.
- Stevens, Marc. "Cryptanalysis of MD5 & SHA-1" (PDF). Retrieved 28 January 2015.
- "SHA-3 standardization". NIST. Retrieved 2015-04-16.
- National Institute of Standards and Technology (Aug 5, 2015). "Federal Information Processing Standards: Permutation-Based Hash and Extendable-Output Functions, etc.". Retrieved 5 Aug 2015.
- "Keccak: The New SHA-3 Encryption Standard". Dr. Dobbs.
- "Joan Daemen". Wikipedia.
- "https://www.federalregister.gov/articles/2015/08/05/2015-19181/announcing-approval-of-federal-information-processing-standard-fips-202-sha-3-standard". 2015-08-05.
- Guido Bertoni, Joan Daemen, Michaël Peeters and Gilles Van Assche. "Sponge Functions". Ecrypt Hash Workshop 2007.
- Guido Bertoni, Joan Daemen, Michaël Peeters and Gilles Van Assche. "On the Indifferentiability of the Sponge Construction". EuroCrypt 2008.
- Keccak implementation overview Version 3.2 http://keccak.noekeon.org/Keccak-implementation-3.2.pdf
- Guo, Xu; Huang, Sinan; Nazhandali, Leyla; Schaumont, Patrick (Aug 2010), "Fair and Comprehensive Performance Evaluation of 14 Second Round SHA-3 ASIC Implementations" (PDF), NIST 2nd SHA-3 Candidate Conference: 12, retrieved 2011-02-18 Keccak is second only to Luffa, which did not advance to the final round.
- NIST, Third-Round Report of the SHA-3 Cryptographic Hash Algorithm Competition, sections 126.96.36.199 (mentioning "tree mode"), 6.2 ("other features", mentioning authenticated encryption), and 7 (saying "extras" may be standardized in the future)
- Daemen, Joan, CAESAR submission: Ketje v1 (PDF)
- Daemen, Joan, CAESAR submission: Keyak v1 (PDF)
- "Keccak parameter changes for round 2".
- "Simplifying Keccak's padding rule for round 3".
- John Kelsey. "SHA3, Where We've Been, Where We're Going" (PDF). RSA Conference 2013.
- John Kelsey. "SHA3, Past, Present, and Future". CHES 2013.
- "NIST hash forum mailing list".
- "The Keccak SHA-3 submission" (PDF). 2011-01-14. Retrieved 2014-02-08.
- "On 128-bit security".
- "A concrete proposal".
- "Schneier on Security: Will Keccak = SHA-3?".
- "LShift: Why I support the US Government making a cryptography standard weaker".
- "Yes, this is Keccak!".
- "Moving Forward with SHA-3" (PDF).
- NIST Computer Security Division (CSD). "SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions" (PDF). NIST.
- "Crypto++ 5.6.0 Benchmarks". Retrieved 2013-06-13.
- Found on an AMD Opteron 8354 2.2 GHz processor running 64-bit Linux
- "Cryptanalysis of MD5 & SHA-1" (PDF). Retrieved 2013-04-25.