Secure Hash Algorithms | |
---|---|
Concepts | |
hash functions, SHA, DSA | |
Main standards | |
SHA-0, SHA-1, SHA-2, SHA-3 | |
General | |
---|---|
Designers | Guido Bertoni, Joan Daemen, Michaël Peeters, and Gilles van Assche. |
First published | 2016 |
Series | (SHA-0), SHA-1, SHA-2, SHA-3 |
Certification | FIPS PUB 202 |
Detail | |
Digest sizes | arbitrary |
Structure | sponge construction |
Speed | 12.6 cpb on a typical x86-64-based machine for Keccak-f[1600] plus XORing 1024 bits, [1] which roughly corresponds to SHA2-256. |
Best public cryptanalysis | |
Preimage attack on Keccak-512 reduced to 8 rounds, requiring 2511.5 time and 2508 memory. [2] Zero-sum distinguishers exist for the full 24-round Keccak-f[1600], though they cannot be used to attack the hash function itself [3] |
SHA-3 (Secure Hash Algorithm 3) is the latest [4] member of the Secure Hash Algorithm family of standards, released by NIST on August 5, 2015. [5] [6] [7] Although part of the same series of standards, SHA-3 is internally different from the MD5-like structure of SHA-1 and SHA-2.
SHA-3 is a subset of the broader cryptographic primitive family Keccak ( /ˈkɛtʃæk/ or /ˈkɛtʃɑːk/ ), [8] [9] designed by Guido Bertoni, Joan Daemen, Michaël Peeters, and Gilles Van Assche, building upon RadioGatún. Keccak's authors have proposed additional uses for the function, not (yet) standardized by NIST, including a stream cipher, an authenticated encryption system, a "tree" hashing scheme for faster hashing on certain architectures, [10] [11] and AEAD ciphers Keyak and Ketje. [12] [13]
Keccak is based on a novel approach called sponge construction. [14] Sponge construction is based on a wide random function or random permutation, and allows inputting ("absorbing" in sponge terminology) any amount of data, and outputting ("squeezing") any amount of data, while acting as a pseudorandom function with regard to all previous inputs. This leads to great flexibility.
As of 2007, NIST did not plan to withdraw SHA-2 or remove it from the revised Secure Hash Standard.[ needs update? ] The purpose of SHA-3 is that it can be directly substituted for SHA-2 in current applications if necessary, and to significantly improve the robustness of NIST's overall hash algorithm toolkit. [15]
For small message sizes, the creators of the Keccak algorithms and the SHA-3 functions suggest using the faster function KangarooTwelve with adjusted parameters and a new tree hashing mode without extra overhead.
The Keccak algorithm is the work of Guido Bertoni, Joan Daemen (who also co-designed the Rijndael cipher with Vincent Rijmen), Michaël Peeters, and Gilles Van Assche. It is based on earlier hash function designs PANAMA and RadioGatún. PANAMA was designed by Daemen and Craig Clapp in 1998. RadioGatún, a successor of PANAMA, was designed by Daemen, Peeters, and Van Assche, and was presented at the NIST Hash Workshop in 2006. [16] The reference implementation source code was dedicated to public domain via CC0 waiver. [17]
In 2006, NIST started to organize the NIST hash function competition to create a new hash standard, SHA-3. SHA-3 is not meant to replace SHA-2, as no significant attack on SHA-2 has been publicly demonstrated [ needs update ]. Because of the successful attacks on MD5, SHA-0 and SHA-1, [18] [19] NIST perceived a need for an alternative, dissimilar cryptographic hash, which became SHA-3.
After a setup period, admissions were to be submitted by the end of 2008. Keccak was accepted as one of the 51 candidates. In July 2009, 14 algorithms were selected for the second round. Keccak advanced to the last round in December 2010. [20]
During the competition, entrants were permitted to "tweak" their algorithms to address issues that were discovered. Changes that have been made to Keccak are: [21] [22]
On October 2, 2012, Keccak was selected as the winner of the competition. [8]
In 2014, the NIST published a draft FIPS 202 "SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions". [23] FIPS 202 was approved on August 5, 2015. [24]
On August 5, 2015, NIST announced that SHA-3 had become a hashing standard. [25]
In early 2013 NIST announced they would select different values for the "capacity", the overall strength vs. speed parameter, for the SHA-3 standard, compared to the submission. [26] [27] The changes caused some turmoil.
The hash function competition called for hash functions at least as secure as the SHA-2 instances. It means that a d-bit output should have d/2-bit resistance to collision attacks and d-bit resistance to preimage attacks, the maximum achievable for d bits of output. Keccak's security proof allows an adjustable level of security based on a "capacity" c, providing c/2-bit resistance to both collision and preimage attacks. To meet the original competition rules, Keccak's authors proposed c = 2d. The announced change was to accept the same d/2-bit security for all forms of attack and standardize c = d. This would have sped up Keccak by allowing an additional d bits of input to be hashed each iteration. However, the hash functions would not have been drop-in replacements with the same preimage resistance as SHA-2 any more; it would have been cut in half, making it vulnerable to advances in quantum computing, which effectively would cut it in half once more. [28]
In September 2013, Daniel J. Bernstein suggested on the NIST hash-forum mailing list [29] to strengthen the security to the 576-bit capacity that was originally proposed as the default Keccak, in addition to and not included in the SHA-3 specifications. [30] This would have provided at least a SHA3-224 and SHA3-256 with the same preimage resistance as their SHA-2 predecessors, but SHA3-384 and SHA3-512 would have had significantly less preimage resistance than their SHA-2 predecessors. In late September, the Keccak team responded by stating that they had proposed 128-bit security by setting c = 256 as an option already in their SHA-3 proposal. [31] Although the reduced capacity was justifiable in their opinion, in the light of the negative response, they proposed raising the capacity to c = 512 bits for all instances. This would be as much as any previous standard up to the 256-bit security level, while providing reasonable efficiency, [32] but not the 384-/512-bit preimage resistance offered by SHA2-384 and SHA2-512. The authors stated that "claiming or relying on security strength levels above 256 bits is meaningless".
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. [33]
He later retracted 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. [33]
Paul Crowley, a cryptographer and 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. [34]
There was some confusion that internal changes may have been made to Keccak, which were cleared up by the original team, 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. [35]
In response to the controversy, in November 2013 John Kelsey of NIST proposed to go back to the original c = 2d proposal for all SHA-2 drop-in replacement instances. [36] The reversion was confirmed in subsequent drafts [37] and in the final release. [5]
SHA-3 uses the sponge construction, [14] in which data is "absorbed" into the sponge, then the result is "squeezed" out. In the absorbing phase, message blocks are XORed into a subset of the state, which is then transformed as a whole using a permutation function . (Calling a permutation may be confusing. It is technically a permutation of the state space, thus a permutation of a set with elements, but it does more than merely permute the bits of the state vector.[ citation needed ]) In the "squeeze" phase, output blocks are read from the same subset of the state, alternated with the state transformation function . The size of the part of the state that is written and read is called the "rate" (denoted ), and the size of the part that is untouched by input/output is called the "capacity" (denoted ). The capacity determines the security of the scheme. The maximum security level is half the capacity.
Given an input bit string , a padding function , a permutation function that operates on bit blocks of width , a rate and an output length , we have capacity and the sponge construction , yielding a bit string of length , works as follows: [6] : 18
The fact that the internal state S contains c additional bits of information in addition to what is output to Z prevents the length extension attacks that SHA-2, SHA-1, MD5 and other hashes based on the Merkle–Damgård construction are susceptible to.
In SHA-3, the state S consists of a 5 × 5 array of w-bit words (with w = 64), b = 5 × 5 × w = 5 × 5 × 64 = 1600 bits total. Keccak is also defined for smaller power-of-2 word sizes w down to 1 bit (total state of 25 bits). 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. [12] [13]
For SHA3-224, SHA3-256, SHA3-384, and SHA3-512 instances, r is greater than d, so there is no need for additional block permutations in the squeezing phase; the leading d bits of the state are the desired hash. However, SHAKE128 and SHAKE256 allow an arbitrary output length, which is useful in applications such as optimal asymmetric encryption padding.
To ensure the message can be evenly divided into r-bit blocks, padding is required. SHA-3 uses the pattern 10…01 in its padding function: a 1 bit, followed by zero or more 0 bits (maximum r − 1) and a final 1 bit.
The maximum of r − 1 zero bits occurs when the last message block is r − 1 bits long. Then another block is added after the initial 1 bit, containing r − 1 zero bits before the final 1 bit.
The two 1 bits will be added even if the length of the message is already divisible by r. [6] : 5.1 In this case, another block is added to the message, containing a 1 bit, followed by a block of r − 2 zero bits and another 1 bit. This is necessary so that a message with length divisible by r ending in something that looks like padding does not produce the same hash as the message with those bits removed.
The initial 1 bit is required so messages differing only in a few additional 0 bits at the end do not produce the same hash.
The position of the final 1 bit indicates which rate r was used (multi-rate padding), which is required for the security proof to work for different hash variants. Without it, different hash variants of the same short message would be the same up to truncation.
The block transformation f, which is Keccak-f[1600] for SHA-3, is a permutation that uses XOR, AND and NOT operations, and is designed for easy implementation in both software and hardware.
It 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 and row-major indexing. I.e. i selects the row, j the column, and k the bit.
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ℓ rounds of five steps:
The speed of SHA-3 hashing of long messages is dominated by the computation of f = Keccak-f[1600] and XORing S with the extended Pi, an operation on b = 1600 bits. However, since the last c bits of the extended Pi are 0 anyway, and XOR with 0 is a NOP, it is sufficient to perform XOR operations only for r bits (r = 1600 − 2 × 224 = 1152 bits for SHA3-224, 1088 bits for SHA3-256, 832 bits for SHA3-384 and 576 bits for SHA3-512). The lower r is (and, conversely, the higher c = b − r = 1600 − r), the less efficient but more secure the hashing becomes since fewer bits of the message can be XORed into the state (a quick operation) before each application of the computationally expensive f. The authors report the following speeds for software implementations of Keccak-f[1600] plus XORing 1024 bits, [1] which roughly corresponds to SHA3-256:
For the exact SHA3-256 on x86-64, Bernstein measures 11.7–12.25 cpb depending on the CPU. [39] : 7 SHA-3 has been criticized for being slow on instruction set architectures (CPUs) which do not have instructions meant specially for computing Keccak functions faster – SHA2-512 is more than twice as fast as SHA3-512, and SHA-1 is more than three times as fast on an Intel Skylake processor clocked at 3.2 GHz. [40] The authors have reacted to this criticism by suggesting to use SHAKE128 and SHAKE256 instead of SHA3-256 and SHA3-512, at the expense of cutting the preimage resistance in half (but while keeping the collision resistance). With this, performance is on par with SHA2-256 and SHA2-512.
However, in hardware implementations, SHA-3 is notably faster than all other finalists, [41] and also faster than SHA-2 and SHA-1. [40]
As of 2018, ARM's ARMv8 [42] architecture includes special instructions which enable Keccak algorithms to execute faster and IBM's z/Architecture [43] includes a complete implementation of SHA-3 and SHAKE in a single instruction. There have also been extension proposals for RISC-V to add Keccak-specific instructions. [44]
The NIST standard defines the following instances, for message M and output length d: [6] : 20, 23
Instance | Output size d | Rate r = block size | Capacity c | Definition | Security strength in bits of resistance against | ||
---|---|---|---|---|---|---|---|
Collision | Preimage | 2nd preimage | |||||
SHA3-224(M) | 224 | 1152 | 448 | Keccak[448](M|| 01, 224) | 112 | 224 | 224 |
SHA3-256(M) | 256 | 1088 | 512 | Keccak[512](M|| 01, 256) | 128 | 256 | 256 |
SHA3-384(M) | 384 | 832 | 768 | Keccak[768](M|| 01, 384) | 192 | 384 | 384 |
SHA3-512(M) | 512 | 576 | 1024 | Keccak[1024](M|| 01, 512) | 256 | 512 | 512 |
SHAKE128(M, d) | d | 1344 | 256 | Keccak[256](M|| 1111, d) | min(d/2,128) | ≥min(d,128) | min(d,128) |
SHAKE256(M, d) | d | 1088 | 512 | Keccak[512](M|| 1111, d) | min(d/2,256) | ≥min(d,256) | min(d,256) |
With the following definitions
SHA-3 instances are drop-in replacements for SHA-2, intended to have identical security properties.
SHAKE will generate as many bits from its sponge as requested, thus being extendable-output functions (XOFs). For example, SHAKE128(M, 256) can be used as a hash function with a 256 character bitstream with 128-bit security strength. Arbitrarily large lengths can be used as pseudo-random number generators. Alternately, SHAKE256(M, 128) can be used as a hash function with a 128-bit length and 128-bit resistance. [6]
All instances append some bits to the message, the rightmost of which represent the domain separation suffix. The purpose of this is to ensure that it is not possible to construct messages that produce the same hash output for different applications of the Keccak hash function. The following domain separation suffixes exist: [6] [45]
Suffix | Meaning |
---|---|
...0 | reserved for future use |
01 | SHA-3 |
...11 | RawSHAKE |
1111 | SHAKE |
In December 2016 NIST published a new document, NIST SP.800-185, [46] describing additional SHA-3-derived functions:
Instance | Description |
---|---|
cSHAKE128(X, L, N, S) | A version of SHAKE supporting explicit domain separation via customization parameters. |
cSHAKE256(X, L, N, S) | |
KMAC128(K, X, L, S) | A keyed hash function based on Keccak. Can also be used without a key as a regular hash function. |
KMAC256(K, X, L, S) | |
KMACXOF128(K, X, L, S) | |
KMACXOF256(K, X, L, S) | |
TupleHash128(X, L, S) | A function for hashing tuples of strings. The output of this function depends on both the contents and the sequence of input strings. |
TupleHash256(X, L, S) | |
TupleHashXOF128(X, L, S) | |
TupleHashXOF256(X, L, S) | |
ParallelHash128(X, B, L, S) | A function designed to exploit parallelism in modern processors for faster hashing. Unlike KangarooTwelve, does not use reduced-round Keccak. |
ParallelHash256(X, B, L, S) | |
ParallelHashXOF128(X, B, L, S) | |
ParallelHashXOF256(X, B, L, S) |
• X is the main input bit string. It may be of any length, including zero.
• L is an integer representing the requested output length in bits.
• N is a function-name bit string, used by NIST to define functions based on cSHAKE. When no function other than cSHAKE is desired, N is set to the empty string.
• S is a customization bit string. The user selects this string to define a variant of the function. When no customization is desired, S is set to the empty string.
• K is a key bit string of any length, including zero.
• B is the block size in bytes for parallel hashing. It may be any integer such that 0 < B < 22040.
General | |
---|---|
Designers | Guido Bertoni, Joan Daemen, Michaël Peeters, Gilles Van Assche, Ronny Van Keer, Benoît Viguier |
First published | August 10, 2016 |
Derived from | Keccak |
Detail | |
Digest sizes | arbitrary |
Structure | sponge construction and tree hashing with kangaroo hopping |
Rounds | 12 |
Speed | 0.51 cpb on SkylakeX with AVX-512 [47] |
Best public cryptanalysis | |
Same as Keccak's |
In 2016 the same team that made the SHA-3 functions and the Keccak algorithm introduced faster reduced-rounds (reduced to 12 and 14 rounds, from the 24 in SHA-3) alternatives which can exploit the availability of parallel execution because of using tree hashing: KangarooTwelve and MarsupilamiFourteen. [48]
These functions differ from ParallelHash, the FIPS standardized Keccak-based parallelizable hash function, with regard to the parallelism, in that they are faster than ParallelHash for small message sizes.
The reduced number of rounds is justified by the huge cryptanalytic effort focused on Keccak which did not produce practical attacks on anything close to twelve-round Keccak. These higher-speed algorithms are not part of SHA-3 (as they are a later development), and thus are not FIPS compliant; but because they use the same Keccak permutation they are secure for as long as there are no attacks on SHA-3 reduced to 12 rounds. [48]
KangarooTwelve is a higher-performance reduced-round (from 24 to 12 rounds) version of Keccak which claims to have 128 bits of security [49] while having performance as high as 0.55 cycles per byte on a Skylake CPU. [50] This algorithm is an IETF RFC draft. [51]
MarsupilamiFourteen, a slight variation on KangarooTwelve, uses 14 rounds of the Keccak permutation and claims 256 bits of security. Note that 256-bit security is not more useful in practice than 128-bit security, but may be required by some standards. [49] 128 bits are already sufficient to defeat brute-force attacks on current hardware, so having 256-bit security does not add practical value, unless the user is worried about significant advancements in the speed of classical computers. For resistance against quantum computers, see below.
KangarooTwelve and MarsupilamiFourteen are Extendable-Output Functions, similar to SHAKE, therefore they generate closely related output for a common message with different output length (the longer output is an extension of the shorter output). Such property is not exhibited by hash functions such as SHA-3 or ParallelHash (except of XOF variants). [6]
In 2016, the Keccak team released a different construction called Farfalle construction, and Kravatte, an instance of Farfalle using the Keccak-p permutation, [52] as well as two authenticated encryption algorithms Kravatte-SANE and Kravatte-SANSE [53]
RawSHAKE is the basis for the Sakura coding for tree hashing, which has not been standardized yet. Sakura uses a suffix of 1111 for single nodes, equivalent to SHAKE, and other generated suffixes depending on the shape of the tree. [45] : 16
There is a general result (Grover's algorithm) that quantum computers can perform a structured preimage attack in , while a classical brute-force attack needs 2d. A structured preimage attack implies a second preimage attack [28] and thus a collision attack. A quantum computer can also perform a birthday attack, thus break collision resistance, in [54] (although that is disputed). [55] Noting that the maximum strength can be , this gives the following upper [56] bounds on the quantum security of SHA-3:
Instance | Security strength in bits of resistance against | |||
---|---|---|---|---|
Collision (Brassard et al.) | Collision (Bernstein) | Preimage | 2nd preimage | |
SHA3-224(M) | 742⁄3 | 112 | 112 | 112 |
SHA3-256(M) | 851⁄3 | 128 | 128 | 128 |
SHA3-384(M) | 128 | 192 | 192 | 192 |
SHA3-512(M) | 1702⁄3 | 256 | 256 | 256 |
SHAKE128(M, d) | min(d/3,128) | min(d/2,128) | ≥min(d/2,128) | min(d/2,128) |
SHAKE256(M, d) | min(d/3,256) | min(d/2,256) | ≥min(d/2,256) | min(d/2,256) |
It has been shown that the Merkle–Damgård construction, as used by SHA-2, is collapsing and, by consequence, quantum collision-resistant, [57] but for the sponge construction used by SHA-3, the authors provide proofs only for the case when the block function f is not efficiently invertible; Keccak-f[1600], however, is efficiently invertible, and so their proof does not apply. [58] [ original research ]
The following hash values are from NIST.gov: [59]
SHA3-224("") 6b4e03423667dbb73b6e15454f0eb1abd4597f9a1b078e3f5b5a6bc7 SHA3-256("") a7ffc6f8bf1ed76651c14756a061d662f580ff4de43b49fa82d80a4b80f8434a SHA3-384("") 0c63a75b845e4f7d01107d852e4c2485c51a50aaaa94fc61995e71bbee983a2ac3713831264adb47fb6bd1e058d5f004 SHA3-512("") a69f73cca23a9ac5c8b567dc185a756e97c982164fe25859e0d1dcc1475c80a615b2123af1f5f94c11e3e9402c3ac558f500199d95b6d3e301758586281dcd26 SHAKE128("", 256) 7f9c2ba4e88f827d616045507605853ed73b8093f6efbc88eb1a6eacfa66ef26 SHAKE256("", 512) 46b9dd2b0ba88d13233b3feb743eeb243fcd52ea62b81b82b50c27646ed5762fd75dc4ddd8c0f200cb05019d67b592f6fc821c49479ab48640292eacb3b7c4be
Changing a single bit causes each bit 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
In the table below, internal state means the number of bits that are carried over to the next block.
Algorithm and variant | Output size (bits) | Internal state size (bits) | Block size (bits) | Rounds | Operations | Security against collision attacks (bits) | Security against length extension attacks (bits) | Performance on Skylake (median cpb) [60] | First published | ||
---|---|---|---|---|---|---|---|---|---|---|---|
Long messages | 8 bytes | ||||||||||
MD5 (as reference) | 128 | 128 (4 × 32) | 512 | 4 (16 operations in each round) | And, Xor, Or, Rot, Add (mod 232) | ≤ 18 (collisions found) [61] | 0 | 4.99 | 55.00 | 1992 | |
SHA-0 | 160 | 160 (5 × 32) | 512 | 80 | And, Xor, Or, Rot, Add (mod 232) | < 34 (collisions found) | 0 | ≈ SHA-1 | ≈ SHA-1 | 1993 | |
SHA-1 | < 63 (collisions found) [62] | 3.47 | 52.00 | 1995 | |||||||
SHA-2 | SHA-224 SHA-256 | 224 256 | 256 (8 × 32) | 512 | 64 | And, Xor, Or, Rot, Shr, Add (mod 232) | 112 128 | 32 0 | 7.62 7.63 | 84.50 85.25 | 2004 2001 |
SHA-384 | 384 | 512 (8 × 64) | 1024 | 80 | And, Xor, Or, Rot, Shr, Add (mod 264) | 192 | 128 | 5.12 | 135.75 | 2001 | |
SHA-512 | 512 | 256 | 0 [63] | 5.06 | 135.50 | 2001 | |||||
SHA-512/224 SHA-512/256 | 224 256 | 112 128 | 288 256 | ≈ SHA-384 | ≈ SHA-384 | 2012 | |||||
SHA-3 | SHA3-224 SHA3-256 SHA3-384 SHA3-512 | 224 256 384 512 | 1600 (5 × 5 × 64) | 1152 1088 832 576 | 24 [64] | And, Xor, Rot, Not | 112 128 192 256 | 448 512 768 1024 | 8.12 8.59 11.06 15.88 | 154.25 155.50 164.00 164.00 | 2015 |
SHAKE128 SHAKE256 | d (arbitrary) d (arbitrary) | 1344 1088 | min(d/2, 128) min(d/2, 256) | 256 512 | 7.08 8.59 | 155.25 155.50 |
Optimized implementation using AVX-512VL (i.e. from OpenSSL, running on Skylake-X CPUs) of SHA3-256 do achieve about 6.4 cycles per byte for large messages, [65] and about 7.8 cycles per byte when using AVX2 on Skylake CPUs. [66] Performance on other x86, Power and ARM CPUs depending on instructions used, and exact CPU model varies from about 8 to 15 cycles per byte, [67] [68] [69] with some older x86 CPUs up to 25–40 cycles per byte. [70]
Below is a list of cryptography libraries that support SHA-3:
Apple A13 ARMv8 six-core SoC CPU cores have support [71] for accelerating SHA-3 (and SHA-512) using specialized instructions (EOR3, RAX1, XAR, BCAX) from ARMv8.2-SHA crypto extension set. [72]
Some software libraries use vectorization facilities of CPUs to accelerate usage of SHA-3. For example, Crypto++ can use SSE2 on x86 for accelerating SHA3, [73] and OpenSSL can use MMX, AVX-512 or AVX-512VL on many x86 systems too. [74] Also POWER8 CPUs implement 2x64-bit vector rotate, defined in PowerISA 2.07, which can accelerate SHA-3 implementations. [75] Most implementations for ARM do not use Neon vector instructions as scalar code is faster. ARM implementations can however be accelerated using SVE and SVE2 vector instructions; these are available in the Fujitsu A64FX CPU for instance. [76]
The IBM z/Architecture supports SHA-3 since 2017 as part of the Message-Security-Assist Extension 6. [77] The processors support a complete implementation of the entire SHA-3 and SHAKE algorithms via the KIMD and KLMD instructions using a hardware assist engine built into each core.
In cryptography, an HMAC is a specific type of message authentication code (MAC) involving a cryptographic hash function and a secret cryptographic key. As with any MAC, it may be used to simultaneously verify both the data integrity and authenticity of a message. An HMAC is a type of keyed hash function that can also be used in a key derivation scheme or a key stretching scheme.
In cryptography, SHA-1 is a hash function which takes an input and produces a 160-bit (20-byte) hash value known as a message digest – typically rendered as 40 hexadecimal digits. It was designed by the United States National Security Agency, and is a U.S. Federal Information Processing Standard. The algorithm has been cryptographically broken but is still widely used.
A cryptographic hash function (CHF) is a hash algorithm that has special properties desirable for a cryptographic application:
Joan Daemen is a Belgian cryptographer who is currently professor of digital security at Radboud University. He co-designed with Vincent Rijmen the Rijndael cipher, which was selected as the Advanced Encryption Standard (AES) in 2001. More recently, he co-designed the Keccak cryptographic hash, which was selected as the new SHA-3 hash by NIST in October 2012. He has also designed or co-designed the MMB, Square, SHARK, NOEKEON, 3-Way, and BaseKing block ciphers. In 2017 he won the Levchin Prize for Real World Cryptography "for the development of AES and SHA3". He describes his development of encryption algorithms as creating the bricks which are needed to build the secure foundations online.
The Secure Hash Algorithms are a family of cryptographic hash functions published by the National Institute of Standards and Technology (NIST) as a U.S. Federal Information Processing Standard (FIPS), including:
SHA-2 is a set of cryptographic hash functions designed by the United States National Security Agency (NSA) and first published in 2001. They are built using the Merkle–Damgård construction, from a one-way compression function itself built using the Davies–Meyer structure from a specialized block cipher.
FORK-256 is a hash algorithm designed in response to security issues discovered in the earlier SHA-1 and MD5 algorithms. After substantial cryptanalysis, the algorithm is considered broken.
In cryptography, a one-way compression function is a function that transforms two fixed-length inputs into a fixed-length output. The transformation is "one-way", meaning that it is difficult given a particular output to compute inputs which compress to that output. One-way compression functions are not related to conventional data compression algorithms, which instead can be inverted exactly or approximately to the original data.
In cryptography, the Merkle–Damgård construction or Merkle–Damgård hash function is a method of building collision-resistant cryptographic hash functions from collision-resistant one-way compression functions. This construction was used in the design of many popular hash algorithms such as MD5, SHA-1 and SHA-2.
Panama is a cryptographic primitive which can be used both as a hash function and a stream cipher, but its hash function mode of operation has been broken and is not suitable for cryptographic use. Based on StepRightUp, it was designed by Joan Daemen and Craig Clapp and presented in the paper Fast Hashing and Stream Encryption with PANAMA on the Fast Software Encryption (FSE) conference 1998. The cipher has influenced several other designs, for example MUGI and SHA-3.
RadioGatún is a cryptographic hash primitive created by Guido Bertoni, Joan Daemen, Michaël Peeters, and Gilles Van Assche. It was first publicly presented at the NIST Second Cryptographic Hash Workshop, held in Santa Barbara, California, on August 24–25, 2006, as part of the NIST hash function competition. The same team that developed RadioGatún went on to make considerable revisions to this cryptographic primitive, leading to the Keccak SHA-3 algorithm.
Skein is a cryptographic hash function and one of five finalists in the NIST hash function competition. Entered as a candidate to become the SHA-3 standard, the successor of SHA-1 and SHA-2, it ultimately lost to NIST hash candidate Keccak.
The NIST hash function competition was an open competition held by the US National Institute of Standards and Technology (NIST) to develop a new hash function called SHA-3 to complement the older SHA-1 and SHA-2. The competition was formally announced in the Federal Register on November 2, 2007. "NIST is initiating an effort to develop one or more additional hash algorithms through a public competition, similar to the development process for the Advanced Encryption Standard (AES)." The competition ended on October 2, 2012, when NIST announced that Keccak would be the new SHA-3 hash algorithm.
The following tables compare general and technical information for a number of cryptographic hash functions. See the individual functions' articles for further information. This article is not all-inclusive or necessarily up-to-date. An overview of hash function security/cryptanalysis can be found at hash function security summary.
The following outline is provided as an overview of and topical guide to cryptography:
BLAKE is a cryptographic hash function based on Daniel J. Bernstein's ChaCha stream cipher, but a permuted copy of the input block, XORed with round constants, is added before each ChaCha round. Like SHA-2, there are two variants differing in the word size. ChaCha operates on a 4×4 array of words. BLAKE repeatedly combines an 8-word hash value with 16 message words, truncating the ChaCha result to obtain the next hash value. BLAKE-256 and BLAKE-224 use 32-bit words and produce digest sizes of 256 bits and 224 bits, respectively, while BLAKE-512 and BLAKE-384 use 64-bit words and produce digest sizes of 512 bits and 384 bits, respectively.
In cryptography, a sponge function or sponge construction is any of a class of algorithms with finite internal state that take an input bit stream of any length and produce an output bit stream of any desired length. Sponge functions have both theoretical and practical uses. They can be used to model or implement many cryptographic primitives, including cryptographic hashes, message authentication codes, mask generation functions, stream ciphers, pseudo-random number generators, and authenticated encryption.
Gilles Van Assche is a Belgian cryptographer who co-designed the Keccak cryptographic hash, which was selected as the new SHA-3 hash by NIST in October 2012. The SHA-3 standard was released by NIST on August 5, 2015.
Shabal is a cryptographic hash function submitted by the France-funded research project Saphir to NIST's international competition on hash functions.
Ascon is a family of lightweight authenticated ciphers that had been selected by US National Institute of Standards and Technology (NIST) for future standardization of the lightweight cryptography.