Escolar Documentos
Profissional Documentos
Cultura Documentos
SUBCATEGORY: CRYPTOGRAPHY
FOREWORD
The Federal Information Processing Standards (FIPS) Publication Series of the National
Institute of Standards and Technology (NIST) is the official series of publications relating
to standards and guidelines adopted and promulgated under the provisions of the Federal
Information Security Management Act (FISMA) of 2002.
Comments concerning FIPS publications are welcomed and should be addressed to the
Director, Information Technology Laboratory, National Institute of Standards and
Technology, 100 Bureau Drive, Stop 8900, Gaithersburg, MD 20899-8900.
Charles H. Romine, Director
Information Technology Laboratory
ii
Abstract
This Standard specifies the Secure Hash Algorithm-3 (SHA-3) family of functions on
binary data. Each of the SHA-3 functions is based on an instance of the KECCAK
algorithm that NIST selected as the winner of the SHA-3 Cryptographic Hash Algorithm
Competition. This Standard also specifies the KECCAK-p family of mathematical
permutations, including the permutation that underlies KECCAK, in order to facilitate the
development of additional permutation-based cryptographic functions.
The SHA-3 family consists of four cryptographic hash functions, called SHA3-224,
SHA3-256, SHA3-384, and SHA3-512, and two extendable-output functions (XOFs),
called SHAKE128 and SHAKE256.
Hash functions are components for many important information security applications,
including 1) the generation and verification of digital signatures, 2) key derivation, and 3)
pseudorandom bit generation. The hash functions specified in this Standard supplement
the SHA-1 hash function and the SHA-2 family of hash functions that are specified in
FIPS 180-4, the Secure Hash Standard.
Extendable-output functions are different from hash functions, but it is possible to use
them in similar ways, with the flexibility to be adapted directly to the requirements of
individual applications, subject to additional security considerations.
iii
Federal Information
Processing Standards Publication 202
August 2015
Announcing the
iv
The four SHA-3 hash functions specified in this Standard supplement the hash functions that are
specified in FIPS 180-4 [1]: SHA-1 and the SHA-2 family. Together, both Standards provide
resilience against future advances in hash function analysis, because they rely on fundamentally
different design principles. In addition to design diversity, the hash functions in this Standard
provide some complementary implementation and performance characteristics to those in FIPS
180-4.
For XOFs, the length of the output can be chosen to meet the requirements of individual
applications. The XOFs can be specialized to hash functions, subject to additional security
considerations, or used in a variety of other applications. The approved uses of XOFs will be
specified in NIST Special Publications.
The KECCAK-p permutations were designed to be suitable as the main components for a variety
of cryptographic functions, including keyed functions for authentication and/or encryption. The
six SHA-3 functions can be considered as modes of operation (modes) of the KECCAKp[1600,24] permutation. In the future, additional modes of this permutation or other KECCAK-p
permutations may be specified and approved in FIPS publications or in NIST Special
Publications.
4. Approving Authority: Secretary of Commerce.
5. Maintenance Agency: U.S. Department of Commerce, National Institute of Standards and
Technology (NIST), Information Technology Laboratory (ITL).
6. Applicability: This Standard is applicable to all Federal departments and agencies for the
protection of sensitive unclassified information that is not subject to Title 10 United States Code
Section 2315 (10 USC 2315) and that is not within a national security system as defined in Title
40 United States Code Section 11103(a)(1) (40 USC 11103(a)(1)). Either this Standard or
Federal Information Processing Standard (FIPS) 180 must be implemented wherever a secure
hash algorithm is required for Federal applications, including as a component within other
cryptographic algorithms and protocols. This Standard may be adopted and used by non-Federal
Government organizations.
7. Specifications: Federal Information Processing Standard (FIPS) 202, SHA-3 Standard:
Permutation-Based Hash and Extendable-Output Functions (affixed).
8. Implementations: Federal departments and agencies shall only use implementations of the
KECCAK-p permutations within FIPS-approved or NIST-recommended modes of operation, such
as the SHA-3 functions that are specified in this Standard. The SHA-3 functions may be
implemented in software, firmware, hardware or any combination thereof. Only implementations
of these functions that are validated by the Cryptographic Algorithm Validation Program will be
considered as complying with this Standard. Information about the validation program can be
obtained at http://csrc.nist.gov/groups/STM/cavp/index.html.
vi
INTRODUCTION ................................................................................................................................................1
GLOSSARY ..........................................................................................................................................................2
2.1
2.2
2.3
2.4
KECCAK-P PERMUTATIONS..........................................................................................................................7
3.1
3.2
3.3
3.4
STATE ................................................................................................................................................7
3.1.1 Parts of the State Array ........................................................................................................8
3.1.2 Converting Strings to State Arrays .......................................................................................9
3.1.3 Converting State Arrays to Strings ..................................................................................... 10
3.1.4 Labeling Convention for the State Array ............................................................................ 11
STEP MAPPINGS ............................................................................................................................... 11
3.2.1 Specification of ................................................................................................................ 11
3.2.2 Specification of ................................................................................................................ 12
3.2.3 Specification of ................................................................................................................ 14
3.2.4 Specification of ................................................................................................................ 15
3.2.5 Specification of ................................................................................................................. 15
KECCAK-p[b, nr] .............................................................................................................................. 16
COMPARISON WITH KECCAK-f ......................................................................................................... 17
KECCAK ............................................................................................................................................................. 19
5.1
5.2
CONFORMANCE .............................................................................................................................................. 21
SECURITY ......................................................................................................................................................... 23
A.1
A.2
SUMMARY........................................................................................................................................ 23
ADDITIONAL CONSIDERATION FOR EXTENDABLE-OUTPUT FUNCTIONS .......................................... 24
EXAMPLES........................................................................................................................................................ 25
B.1
B.2
REFERENCES ................................................................................................................................................... 28
vii
Figures
Figure 1:
Figure 2:
Figure 3:
Figure 4:
Figure 5:
Figure 6:
Figure 7:
Table 1:
Table 2:
Table 3:
Table 4:
Table 5:
Table 6:
viii
1 INTRODUCTION
This Standard specifies a new family of functions that supplement SHA-1 and the SHA-2 family
of hash functions specified in FIPS 180-4 [1]. This family, called SHA-3 (Secure Hash
Algorithm-3), is based on KECCAK [2]the algorithm1 that NIST selected as the winner of the
public SHA-3 Cryptographic Hash Algorithm Competition [3]. The SHA-3 family consists of
four cryptographic hash functions and two extendable-output functions. These six functions
share the structure that is described in [4], namely, the sponge construction; functions with this
structure are called sponge functions.
A hash function is a function on binary data (i.e., bit strings) for which the length of the output is
fixed.2 The input to a hash function is called the message, and the output is called the (message)
digest or hash value. The digest often serves as a condensed representation of the message. The
four SHA-3 hash functions are named SHA3-224, SHA3-256, SHA3-384, and SHA3-512; in
each case, the suffix after the dash indicates the fixed length of the digest, e.g., SHA3-256
produces 256-bit digests. The SHA-2 functions, i.e., SHA-224, SHA-256, SHA-384 SHA-512,
SHA-512/224, and SHA-512/256, offer the same set of digest lengths. Thus, the SHA-3 hash
functions can be implemented as alternatives to the SHA-2 functions, or vice versa.
An extendable-output function (XOF) is a function on bit strings (also called messages) in which
the output can be extended to any desired length. The two SHA-3 XOFs are named SHAKE128
and SHAKE256.3 The suffixes 128 and 256 indicate the security strengths that these two
functions can generally4 support, in contrast to the suffixes for the hash functions, which indicate
the digest lengths. SHAKE128 and SHAKE256 are the first XOFs that NIST has standardized.
The six SHA-3 functions are designed to provide special properties, such as resistance to
collision, preimage, and second preimage attacks. The level of resistance to these three types of
attacks is summarized in Sec. A.1. Cryptographic hash functions are fundamental components in
a variety of information security applications, such as digital signature generation and
verification, key derivation, and pseudorandom bit generation.
The digest lengths in FIPS-approved hash functions are 160, 224, 256, 384, and 512 bits. When
an application requires a cryptographic hash function with a non-standard digest length, an XOF
is a natural alternative to constructions that involve multiple invocations of a hash function
and/or truncation of the output bits. However, XOFs are subject to the additional security
consideration that is described in Sec. A.2.
Each of the six SHA-3 functions employs the same underlying permutation as the main
component in the sponge construction. In effect, the SHA-3 functions are modes of operation
More precisely, the competition called for four hash functions, and KECCAK is a larger family of functions.
For many hash functions, there is a (very large) bound on the length of the input data.
3
The name SHAKE was proposed in [5] to combine the term Secure Hash Algorithm with KECCAK.
4
An exception is when the output length is sufficiently small; see the discussion in Sec. A.1.
2
2 GLOSSARY
2.1 Terms and Acronyms
bit
byte
capacity
In the sponge construction, the width of the underlying function minus the
rate.
column
For a state array, a sub-array of five bits with constant x and z coordinates.
digest
The output of a cryptographic hash function. Also called the hash value.
domain separation
extendable-output
function (XOF)
FIPS
FISMA
hash function
A function on bit strings in which the length of the output is fixed. The
output often serves as a condensed representation of the input.
2
hash value
See digest.
HMAC
KDF
KECCAK
lane
message
multi-rate padding
NIST
plane
rate
round
round constant
round index
The value of the integer index for the rounds of a KECCAK-p permutation.
row
For a state array, a sub-array of five bits with constant y and z coordinates.
SHA-3
SHAKE
sheet
slice
sponge construction The method originally specified in [4] for defining a function from the
following: 1) an underlying function on bit strings of a fixed length, 2) a
padding rule, and 3) a rate. Both the input and the output of the resulting
function are bit strings that can be arbitrarily long.
sponge function
state
state array
step mapping
string
width
In the sponge construction, the fixed length of the inputs and the outputs
of the underlying function.
XOF
XOR
A state array.
A[x, y, z]
For a state array A, the bit that corresponds to the triple (x, y, z).
The length of the digest of a hash function or the requested length of the
output of an XOF, in bits.
ir
For a KECCAK-p permutation, the binary logarithm of the lane size, i.e.,
log2(w).
Lane (i, j)
For a state array A, a string of all the bits of the lane whose x and y
coordinates are i and j.
nr
pad
Plane (j)
For a state array A, a string of all the bits of the plane whose y coordinate
is j.
RC
len(X)
X[i]
For a string X and an integer i such that 0 i < len(X), X[i] is the bit of X
with index i. Bit strings are depicted with indices increasing from left to
right, so that X[0] appears at the left, followed by X[1], etc. For example,
if X = 101000, then X[2] = 1.
Truncs (X)
For a positive integer s and a string X, Truncs (X) is the string comprised of
bits X[0] to X[s 1]. For example, Trunc2(10100) = 10.
XY
For strings X and Y of equal bit length, X Y is the string that results from
applying the Boolean exclusive-OR operation to X and Y at each bit
position. For example, 1100 1010 = 0110.
X || Y
m/n
m mod n
For integers m and n, m mod n is the integer r for which 0 r < n and mr
is a multiple of n. For example, 11 mod 5 = 1, and 11 mod 5 = 4.
For a real number x, x is the least integer that is not strictly less than x.
For example, 3.2 = 4, 3.2 = 3, and 6 = 6.
log2(x)
For a positive real number x, log2(x) is the real number y such that 2y = x.
min(x, y)
KECCAK[c]
KECCAK-f [b]
KECCAK-p[b, nr]
pad10*1
RawSHAKE128
RawSHAKE256
rc
The function that generates the variable bits of the round constants.
Rnd
SHA3-224
SHA3-256
SHA3-384
SHA3-512
SHAKE128
The SHA-3 XOF that generally supports 128 bits of security strength, if
The SHA-3 XOF that generally supports 256 bits of security strength, if
the output is sufficiently long; see Sec. A.1.
SPONGE[f, pad, r]
3 KECCAK-p PERMUTATIONS
In this section, the KECCAK-p permutations are specified, with two parameters: 1) the fixed
length of the strings that are permuted, called the width of the permutation, and 2) the number of
iterations of an internal transformation, called a round. The width is denoted by b, and the
number of rounds is denoted by nr. The KECCAK-p permutation with nr rounds and width b is
denoted by KECCAK-p[b, nr]; the permutation is defined for any b in {25, 50, 100, 200, 400, 800,
1600} and any positive integer nr.
A round of a KECCAK-p permutation, denoted by Rnd, consists of a sequence of five
transformations, which are called the step mappings. The permutation is specified in terms of an
array of values for b bits that is repeatedly updated, called the state; the state is initially set to the
input values of the permutation.
The notation and terminology for the state are described in Sec. 3.1. The step mappings are
specified in Sec. 3.2. The KECCAK-p permutations, including the round function Rnd, are
specified in Sec. 3.3. The relationship of the KECCAK-p permutations to the KECCAK-f
permutations that were defined for KECCAK in [8] is described in Sec. 3.4.
3.1 State
The state for the KECCAK-p[b, nr] permutation is comprised of b bits. The specifications in this
Standard contain two other quantities related to b: b/25 and log2(b/25), denoted by w and l,
respectively. The seven possible values for these variables that are defined for the KECCAK-p
permutations are given in the columns of Table 1 below.
b
w
l
25
1
0
50
2
1
100
4
2
200
8
3
400
16
4
800
32
5
1600
64
6
If A denotes a 5-by-5-by-w array of bits that represents the state, then its indices are the integer
triples (x, y, z) for which 0 x < 5, 0 y < 5, and 0 z < w. The bit that corresponds to (x, y, z) is
denoted by A[x, y, z]. A state array is a representation of the state by a three-dimensional array
that is indexed in this manner.
3.1.1 Parts of the State Array
The state array for a KECCAK-p permutation, and its lower-dimensional sub-arrays, are illustrated
in Figure 1 above for the case b = 200, so that w = 8. The two-dimensional sub-arrays are called
sheets, planes, and slices, and the single-dimensional sub-arrays are called rows, columns, and
lanes. The algebraic definitions of these sub-arrays are given in the Glossary, in Sec. 2.1.
3.1.2 Converting Strings to State Arrays
Let S denote a string of b bits that represents the state for the KECCAK-p[b, nr] permutation. The
corresponding state array, denoted by A, is defined as follows:
For all triples (x, y, z) such that 0 x < 5, 0 y < 5, and 0 z < w,
A[x, y, z] = S [w(5y + x) + z].
For example, if b= 1600, so that w= 64, then
A[0, 0, 0] = S [0]
A[0, 0, 1] = S [1]
A[0, 0, 2] = S [2]
A[1, 0, 0] = S [64]
A[1, 0, 1] = S [65]
A[1, 0, 2] = S [66]
A[0, 1, 0] = S [320]
A[0, 1, 1] = S [321]
A[0, 1, 2] = S [322]
A[1, 1, 0] = S [384]
A[1, 1, 1] = S [385]
A[1, 1, 2] = S [386]
A[4, 1, 0] = S [576]
A[4, 1, 1] = S [577]
A[4, 1, 2] = S [578]
A[0, 2, 0] = S [640]
A[0, 2, 1] = S [641]
A[0, 2, 2] = S [642]
A[1, 2, 0] = S [704]
A[1, 2, 1] = S [705]
A[1, 2, 2] = S [706]
A[4, 2, 0] = S [896]
A[4, 2, 1] = S [897]
A[4, 2, 2] = S [898]
A[4, 0, 0] = S [256]
A[4, 0, 1] = S [257]
A[4, 0, 2] = S [258]
and
and
etc.
10
0
y
1
w
2
1
0
4
3
3 4 0 1 2
x
Figure 2: The x, y, and z coordinates for the diagrams of the step mappings
In the diagrams of the state that accompany the specifications of the step mappings, the lane that
corresponds to the coordinates (x, y) = (0, 0) is depicted at the center of the slices. The complete
labeling of the x, y, and z coordinates for those diagrams is shown in Figure 2 above.
Steps:
1. For all pairs (x, z) such that 0 x < 5 and 0 z < w, let
C[x, z] = A[x, 0, z] A[x, 1, z] A[x, 2, z] A[x, 3, z] A[x, 4, z].
2. For all pairs (x, z) such that 0 x < 5 and 0 z < w let
D[x, z] = C[(x1) mod 5, z] C[(x+1) mod 5, (z 1) mod w].
3. For all triples (x, y, z) such that 0 x < 5, 0 y < 5, and 0 z < w, let
A[x, y, z] = A[x, y, z] D[x, z].
The effect of is to XOR each bit in the state with the parities of two columns in the array. In
particular, for the bit A[x0, y0, z0], the x-coordinate of one of the columns is (x0 1) mod 5, with
the same z-coordinate, z0, while the x-coordinate of the other column is (x0 + 1) mod 5, with zcoordinate (z0 1) mod w.
In the illustration of the step mapping in Figure 3 below, the summation symbol, , indicates
the parity, i.e., the XOR sum of all the bits in the column.
12
y=2
y=1
y=0
y=4
y=3
The offsets for each lane that result from the computation in Step 3a in Algorithm 2 are listed in
Table 2 above.
An illustration of for the case w = 8 is given in Figure 4 below. The labeling convention for the
x and y coordinates in Figure 4 is given explicitly in Figure 2, corresponding to the rows and
columns in Table 2. For example, the lane A[0, 0] is depicted in the middle of the middle sheet,
and the lane A[2, 3] is depicted at the bottom of the right-most sheet.
13
is 0. Consequently, the offsets may be reduced modulo the lane size; e.g., the lane for A[3, 2], at
the top of the left-most sheet, has an offset of 153 mod 8 for this example, i.e., the offset is 1 bit.
3.2.3 Specification of
Algorithm 3: (A)
Input:
state array A.
Output:
state array A.
Steps:
1. For all triples (x, y, z) such that 0 x < 5, 0 y < 5, and 0 z < w, let
A[x, y, z]= A[(x + 3y) mod 5, x, z].
2. Return A.
The effect of is to rearrange the positions of the lanes, as illustrated for any slice in Figure 5
below. The convention for the labeling of the coordinates is depicted in Figure 2 above; for
example, the bit with coordinates x = y = 0 is depicted at the center of the slice.
14
3.2.4 Specification of
Algorithm 4: (A)
Input:
state array A.
Output:
state array A.
Steps:
1. For all triples (x, y, z) such that 0 x < 5, 0 y < 5, and 0 z < w, let
A [x, y, z] = A[x, y, z] ((A[(x+1) mod 5, y, z] 1) A[(x+2) mod 5, y, z]).
2. Return A.
The dot in the right side of the assignment for Step 1 indicates integer multiplication, which in
this case is equivalent to the intended Boolean AND operation.
The effect of is to XOR each bit with a non-linear function of two other bits in its row, as
illustrated in Figure 6 below.
15
Algorithm 5: rc(t)
Input:
integer t.
Output:
bit rc(t).
Steps:
1. If t mod 255 = 0, return 1.
2. Let R = 10000000.
3. For i from 1 to t mod 255, let:
a. R = 0 || R;
b. R[0] = R[0] R[8];
c. R[4] = R[4] R[8];
d. R[5] = R[5] R[8];
e. R[6] = R[6] R[8];
f. R =Trunc8[R].
4. Return R[0].
Algorithm 6: (A, ir)
Input:
state array A;
round index ir.
Output:
state array A.
Steps:
1.
2.
3.
4.
5.
For all triples (x, y, z) such that 0 x < 5, 0 y < 5, and 0 z < w, let A[x, y, z] = A[x, y, z].
Let RC = 0w.
For j from 0 to l, let RC[2j 1] = rc(j + 7ir).
For all z such that 0 z < w, let A [0, 0, z] = A [0, 0, z] RC[z].
Return A.
The effect of is to modify some of the bits of Lane (0, 0) in a manner that depends on the round
index ir. The other 24 lanes are not affected by .
16
4 SPONGE CONSTRUCTION
The sponge construction [4] is a framework for specifying functions on binary data with arbitrary
output length. The construction employs the following three components:
The function that the construction produces from these components is called a sponge function,
denoted by SPONGE[f, pad, r]. A sponge function takes two inputs: a bit string, denoted by N, and
17
the bit length, denoted by d, of the output string, SPONGE[f, pad, r](N, d). The analogy to a sponge
is that an arbitrary number of input bits are absorbed into the state of the function, after which
an arbitrary number of output bits are squeezed out of its state.
The sponge construction is illustrated in Figure 7 below, adapted from [4].
18
Output:
string Z such that len(Z) = d.
Steps:
1. Let P = N || pad(r, len(N)).
2. Let n = len(P)/r.
3. Let c = b r.
4. Let P0, , Pn-1 be the unique sequence of strings of length r such that P = P0 || || Pn1.
5. Let S = 0b.
6. For i from 0 to n1, let S = f (S (Pi || 0c)).
7. Let Z be the empty string.
8. Let Z = Z || Trunc r (S).
9. If d |Z|, then return Trunc d (Z); else continue.
10. Let S = f(S), and continue with Step 8.
Note that the input d determines the number of bits that Algorithm 8 returns, but it does not
affect their values. In principle, the output can be regarded as an infinite string, whose
computation, in practice, is halted after the desired number of output bits is produced.
5 KECCAK
KECCAK is a family of sponge functions, originally defined in [8]. The padding rule for KECCAK,
called multi-rate padding, is specified in Sec. 5.1. The parameters and the underlying
permutations for KECCAK are described in Sec. 5.2, and a smaller family of KECCAK functions,
KECCAK[c], is specified explicitly, which will suffice to define the SHA-3 functions in Sec. 6.
19
7 Conformance
Implementations of the KECCAK-p[1600, 24] permutation and the six SHA-3 modes of this
permutationSHA3-224, SHA3-256, SHA3-384, SHA3-512, SHAKE128, and SHAKE256
may be tested for conformance to this Standard under the auspices of the Cryptographic
Algorithm Validation Program [9].
21
SHA3-224, SHA3-256, SHA3-384, and SHA3-512 are approved cryptographic hash functions.
One of the approved uses of cryptographic hash functions occurs within the Keyed-Hash
Message Authentication Code (HMAC). The input block size in bytes, denoted by B in the
HMAC specification [10], is given in Table 3 below for the SHA-3 hash functions5:
Hash Function
Block Size (bytes)
SHA3-224
144
SHA3-256
136
SHA3-384
104
SHA3-512
72
In general, the input block size (in bits) of a sponge function is its rate.
22
A Security
The detailed analysis of the security properties of KECCAK in [8] applies to the SHA-3 family of
hash and extendable output functions. The SHA-3 family also inherits security properties from
the sponge construction; these properties are analyzed in detail in [4].
Applications of hash functions often require collision resistance, preimage resistance, and/or
second preimage resistance; these properties are summarized for the SHA-3 family of hash
functions and XOFs in Sec. A.1. XOFs differ from hash functions in the generation of closely
related outputs; this important security consideration is discussed in Sec. A.2.
A.1 Summary
As of the publication of this Standard, the security strengths of the SHA-3 functions are
summarized in Table 4. The SHA-1 and SHA-2 functions are included for comparison,
duplicating some of the discussion in [11], which will be updated as necessary with the latest
security information.
Output
Size
Collision
Preimage
2nd Preimage
SHA-1
160
< 80
160
160 L (M)
SHA-224
224
112
224
SHA-512/224
224
112
224
224
SHA-256
256
128
256
256 L (M)
SHA-512/256
256
128
256
256
SHA-384
384
192
384
384
SHA-512
512
256
512
512 L (M)
SHA3-224
224
112
224
224
SHA3-256
256
128
256
256
SHA3-384
384
192
384
384
SHA3-512
512
256
512
512
SHAKE128
min(d/2, 128)
min(d, 128)
min(d, 128)
SHAKE256
min(d/2, 256)
min(d, 256)
min(d, 256)
Function
23
For the security strength against second preimage attacks on a message M, the function L(M) is
defined as log2(len(M)/B), where B is the block length of the function in bits, i.e., B = 512 for
SHA-1, SHA-224, and SHA-256, and B = 1024 for SHA-512.
The four SHA-3 hash functions are alternatives to the SHA-2 functions, and they are designed to
provide resistance against collision, preimage, and second preimage attacks that equals or
exceeds the resistance that the corresponding SHA-2 functions provide. The SHA-3 functions are
also designed to resist other attacks, such as length-extension attacks, that would be resisted by a
random function of the same output length, in general providing the same security strength as a
random function, up to the output length.
The two SHA-3 XOFs are designed to resist collision, preimage, and second-preimage attacks,
and other attacks that would be resisted by a random function of the requested output length, up
to the security strength of 128 bits for SHAKE128, and 256 bits for SHAKE256. A random
function whose output length is d bits cannot provide more than d/2 bits of security against
collision attacks and d bits of security against preimage and second preimage attacks, so
SHAKE128 and SHAKE256 will provide less than 128 and 256 bits of security, respectively,
when d is sufficiently small, as described in Table 4. For example, if d = 224, then SHAKE128
and SHAKE256 provide 112 bits of collision resistance; however, they provide different levels
of preimage resistance: 128 bits for SHAKE128 and 224 bits for SHAKE256.
If d > r + c/2, then SHAKE128 and SHAKE256 provide more than 128 and 256 bits of preimage
resistance, respectively; moreover, if d > 1600, a preimage probably does not exist.
24
almost identical structure. The same statement applies to previously approved hash functions,
including the truncated versions of SHA-512 in FIPS 180-4 (e.g., SHA-512/256).
However, existing mechanisms for constructing functions with arbitrary output lengthby
concatenating and/or truncating digests from hash functionsgenerally do exhibit this property.
The possibility of closely related outputs can affect the security of the
application/protocol/system that invokes an XOF. For example, a nave (and non-approved) way
for two parties to agree to derive a 112-bit Triple DES key from a message designated as
keymaterial would be to compute SHAKE128(keymaterial, keylength), where keylength is 112.
However, if an attacker is able to induce one of the parties to use a different value for keylength,
say 168 bits, but the same value for keymaterial, then the two parties will end up with the
following keys:
SHAKE128(keymaterial, 112) = fg
SHAKE128(keymaterial, 168) = fgh,
where the bolded letters of the digest represent 56-bit strings, e.g., the parts of a Triple DES key.
Because of the structure of Triple DES, these keys are vulnerable to attack.
In practice, the use of an XOF as a key derivation function (KDF) could preclude the possibility
of related outputs, by incorporating the length and/or type of the derived key into the message
input to the KDF. In that case, a disagreement or misunderstanding between two users of the
KDF about the type or length of the key they are deriving would almost certainly not lead to
related outputs.
Where extended digests are problematic, a more general solution is domain separation, by which
different instances of the XOFs could be created and tailored to different purposes, independent
of the number of output bits. All of the SHA-3 functions are designed to allow variants for new,
separate domains that NIST may develop in the future.
B Examples
Examples of the five step mappings and of the six SHA-3 functions are available at the examples
page at NISTs Computer Security Resource Center web site: http://csrc.nist.gov/groups/ST
/toolkit/examples.html.
The bit strings for these examples are represented as hexadecimal strings, i.e., sequences of the
sixteen hexadecimal digits: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, and F, where A is the digit
for ten, B is the digit for eleven, etc.
The convention for interpreting hexadecimal strings as bit strings for the inputs and outputs of
the SHA-3 examples is different from the convention for other functions on the examples page.
The conversion functions between hexadecimal strings and SHA-3 bit strings are specified in
Sec. B.1. For byte-aligned messages, the hexadecimal forms of the padding for the SHA-3
functions are described in Sec. B.2.
25
Specific hexadecimal strings in these sections are written in the Courier New font, preceded
by the marker 0x.
3.
4.
For each integer i such that 0 i < 2m-1, let Hi be the ith hexadecimal digit in H:
H = H0 H1 H2 H3 H2m-2 H2m-1.
For each integer i such that 0 i < m:
a. Let hi = 16 H2i +H2i+1.
b. Let bi0 bi1 bi2 bi3 bi4 bi5 bi6 bi7 be the unique sequence of bits such that
hi = bi7 27 + bi6 26 + bi5 25 + bi4 24 + bi3 23 + bi2 22 + bi1 21 + bi0 20.
For each pair of integers (i, j) such that 0 i < m and 0 j < 8, let T [8i + j] = bij.
Return S = Truncn(T).
In Step 1, the indices are defined for the hexadecimal digits. In Step 2a, each pair of hexadecimal
digits is converted to the (base 10) integer between 0 and 255 that the pair represents in base 16.
In Step 2b, each integer from Step 2a is converted to its binary representation as a byte. In Step
3, the bytes are combined into a single string, and the result is truncated to the desired number of
bits in Step 4.
For example, if H = 0x A3 2E and n = 14, then the intermediate values that are defined in Steps 1
and 2 of Algorithm 10 are indicated in Table 5 below:
H0 = A
H1 = 3
h0 = 16 10 + 3 = 163 =
1 27+0 26+1 25+0 24+0 23+0 22+1 21+
1 20
1
0
1
0
0
0
1
1
b07 b06 b05 b04 b03 b02 b01 b00
H2 = 2
H3 = E
h1 = 16 2 + 14 = 46 =
0 27+0 26+1 25+0 24+1 23+1 22+1 21+
0 20
0
0
1
0
1
1
1
0
b17 b16 b15 b14 b13 b12 b11 b10
26
5.
Let n = len(S).
Let T = S || 0-n mod 8 and m = n/8.
For each pair of integers (i, j) such that 0 i < m and 0 j < 8, let bij = T [8i + j].
For each integer i such that 0 i < m:
a. Let hi = bi7 27 + bi6 26 + bi5 25 + bi4 24 + bi3 23 + bi2 22 + bi1 21 + bi0 20.
b. Let H2i and H2i +1 be the hexadecimal digits such that hi = 16 H2i + H2i+1.
Return H = H0 H1 H2 H3 H2m-2 H2m-1.
The formal bit-reordering function that was specified in [12]for the KECCAK submission to the
SHA-3 competitiongives equivalent conversions when the message is byte-aligned, i.e., when
n is a multiple of 8.
27
The value of q determines the hexadecimal form of these bytes in this case according to the
conversion functions specified in Sec. B.1. The padded messages that result are summarized in
Table 6:
Type of SHA-3 Function Number of Padding Bytes
Padded Message
Hash
q=1
M || 0x86
Hash
q=2
M || 0x0680
Hash
q>2
XOF
q=1
M || 0x9F
XOF
q=2
M || 0x1F80
XOF
q>2
C Object Identifiers
Object identifiers (OIDs) for SHA3-224, SHA3-256, SHA3-384, SHA3-512, SHAKE128, and
SHAKE256 are posted at http://csrc.nist.gov/groups/ST/crypto_apps_infra/csor/algorithms.html.
D References
[1]
[2]
G. Bertoni, J. Daemen, M. Peeters, and G. Van Assche, The KECCAK SHA-3 submission,
Version 3, January 2011, http://keccak.noekeon.org/Keccak-submission-3.pdf.
[3]
[4]
[5]
5,
2012,
Hash
Forum,
[6]
G. Bertoni, J. Daemen, M. Peeters, and G. Van Assche, SAKURA: a flexible coding for tree
hashing, http://keccak.noekeon.org/Sakura.pdf.
[7]
[8]
G. Bertoni, J. Daemen, M. Peeters, and G. Van Assche, The KECCAK reference, Version
3.0, January 2011, http://keccak.noekeon.org/Keccak-reference-3.0.pdf.
[9]
[10]
[11]
[12]
29