idnits 2.17.1 draft-irtf-cfrg-argon2-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 11, 2021) is 1113 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 291 -- Looks like a reference, but probably isn't: '1' on line 291 -- Looks like a reference, but probably isn't: '32' on line 739 -- Looks like a reference, but probably isn't: '16' on line 741 -- Looks like a reference, but probably isn't: '8' on line 742 -- Looks like a reference, but probably isn't: '12' on line 743 -- Looks like a reference, but probably isn't: '124' on line 777 -- Looks like a reference, but probably isn't: '125' on line 778 -- Looks like a reference, but probably isn't: '126' on line 779 -- Looks like a reference, but probably isn't: '127' on line 780 Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CFRG A. Biryukov 3 Internet-Draft D. Dinu 4 Intended status: Informational University of Luxembourg 5 Expires: September 12, 2021 D. Khovratovich 6 ABDK Consulting 7 S. Josefsson 8 SJD AB 9 March 11, 2021 11 The memory-hard Argon2 password hash and proof-of-work function 12 draft-irtf-cfrg-argon2-13 14 Abstract 16 This document describes the Argon2 memory-hard function for password 17 hashing and proof-of-work applications. We provide an implementer- 18 oriented description with test vectors. The purpose is to simplify 19 adoption of Argon2 for Internet protocols. This document is a 20 product of the Crypto Forum Research Group (CFRG) in the IRTF. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 12, 2021. 39 Copyright Notice 41 Copyright (c) 2021 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Notation and Conventions . . . . . . . . . . . . . . . . . . 3 58 3. Argon2 Algorithm . . . . . . . . . . . . . . . . . . . . . . 4 59 3.1. Argon2 Inputs and Outputs . . . . . . . . . . . . . . . . 4 60 3.2. Argon2 Operation . . . . . . . . . . . . . . . . . . . . 5 61 3.3. Variable-length hash function H' . . . . . . . . . . . . 7 62 3.4. Indexing . . . . . . . . . . . . . . . . . . . . . . . . 7 63 3.4.1. Computing the 32-bit values J_1 and J_2 . . . . . . . 8 64 3.4.2. Mapping J_1 and J_2 to reference block index [l][z] . 9 65 3.5. Compression function G . . . . . . . . . . . . . . . . . 10 66 3.6. Permutation P . . . . . . . . . . . . . . . . . . . . . . 11 67 4. Parameter Choice . . . . . . . . . . . . . . . . . . . . . . 12 68 5. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . 14 69 5.1. Argon2d Test Vectors . . . . . . . . . . . . . . . . . . 14 70 5.2. Argon2i Test Vectors . . . . . . . . . . . . . . . . . . 15 71 5.3. Argon2id Test Vectors . . . . . . . . . . . . . . . . . . 16 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 74 7.1. Security as hash function and KDF . . . . . . . . . . . . 18 75 7.2. Security against time-space tradeoff attacks . . . . . . 18 76 7.3. Security for time-bounded defenders . . . . . . . . . . . 19 77 7.4. Recommendations . . . . . . . . . . . . . . . . . . . . . 19 78 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 80 9.1. Normative References . . . . . . . . . . . . . . . . . . 19 81 9.2. Informative References . . . . . . . . . . . . . . . . . 20 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 84 1. Introduction 86 This document describes the Argon2 [ARGON2ESP] memory-hard function 87 for password hashing and proof-of-work applications. We provide an 88 implementer oriented description with test vectors. The purpose is 89 to simplify adoption of Argon2 for Internet protocols. This document 90 corresponds to version 1.3 of the Argon2 hash function. 92 Argon2 is a traditional memory-hard function [HARD]. It is a 93 streamlined design. It aims at the highest memory filling rate and 94 effective use of multiple computing units, while still providing 95 defense against tradeoff attacks. Argon2 is optimized for the x86 96 architecture and exploits the cache and memory organization of the 97 recent Intel and AMD processors. Argon2 has one primary variant: 98 Argon2id and two supplementary variants: Argon2d and Argon2i. 99 Argon2d uses data-dependent memory access, which makes it suitable 100 for cryptocurrencies and proof-of-work applications with no threats 101 from side-channel timing attacks. Argon2i uses data-independent 102 memory access, which is preferred for password hashing and password- 103 based key derivation. Argon2id works as Argon2i for the first half 104 of the first pass over the memory, and as Argon2d for the rest, thus 105 providing both side-channel attack protection and brute-force cost 106 savings due to time-memory tradeoffs. Argon2i makes more passes over 107 the memory to protect from tradeoff attacks [AB15]. 109 Argon2id MUST be supported by any implementation of this document, 110 whereas Argon2d and Argon2i MAY be supported. 112 Argon2 is also a mode of operation over a fixed-input-length 113 compression function G and a variable-input-length hash function H. 114 Even though Argon2 can be potentially used with an arbitrary function 115 H, as long as it provides outputs up to 64 bytes, in this document it 116 is BLAKE2b [BLAKE2]. 118 For further background and discussion, see the Argon2 paper [ARGON2]. 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in RFC 2119 [RFC2119]. 124 This document represents the consensus of the Crypto Forum Research 125 Group (CFRG). 127 2. Notation and Conventions 129 x^y --- integer x multiplied by itself integer y times 131 a*b --- multiplication of integer a and integer b 133 c-d --- subtraction of integer d from integer c 135 E_f --- variable E with subscript index f 137 g / h --- integer g divided by integer h. The result is a rational 138 number 140 I(j) --- function I evaluated at j 142 K || L --- string K concatenated with string L 144 a XOR b --- bitwise exclusive-or between bitstrings a and b 145 a mod b --- remainder of integer a modulo integer b, always in range 146 [0, b-1] 148 a >>> n --- rotation of 64-bit string a to the right by n bits 150 trunc(a) --- the 64-bit value, truncated to the 32 least significant 151 bits 153 floor(a) --- the largest integer not bigger than a 155 ceil(a) --- the smallest integer not smaller than a 157 extract(a, i) --- the i-th set of 32-bits from bitstring a, starting 158 from 0-th 160 |A| --- the number of elements in set A 162 LE32(a) --- 32-bit integer a converted to a bytestring in little 163 endian. Example: 123456 (decimal) is 40 E2 01 00. 165 LE64(a) --- 64-bit integer a converted to a bytestring in little 166 endian. Example: 123456 (decimal) is 40 E2 01 00 00 00 00 00. 168 int32(s) --- 32-bit string s is converted to non-negative integer in 169 little endian. 171 int64(s) --- 64-bit string s is converted to non-negative integer in 172 little endian. 174 length(P) --- the bytelength of string P expressed as 32-bit integer 176 ZERO(P) --- the P-byte zero string 178 3. Argon2 Algorithm 180 3.1. Argon2 Inputs and Outputs 182 Argon2 has the following input parameters: 184 o Message string P, which is a password for password hashing 185 applications. MUST have length not greater than 2^(32) - 1 bytes. 187 o Nonce S, which is a salt for password hashing applications. MUST 188 have length not greater than 2^(32)-1 bytes. 16 bytes is 189 RECOMMENDED for password hashing. Salt SHOULD be unique for each 190 password. 192 o Degree of parallelism p determines how many independent (but 193 synchronizing) computational chains (lanes) can be run. It MUST 194 be an integer value from 1 to 2^(24)-1. 196 o Tag length T MUST be an integer number of bytes from 4 to 2^(32)- 197 1. 199 o Memory size m MUST be an integer number of kibibytes from 8*p to 200 2^(32)-1. The actual number of blocks is m', which is m rounded 201 down to the nearest multiple of 4*p. 203 o Number of passes t (used to tune the running time independently of 204 the memory size) MUST be an integer number from 1 to 2^(32)-1. 206 o Version number v MUST be one byte 0x13. 208 o Secret value K is OPTIONAL. If used, it MUST have length not 209 greater than 2^(32)-1 bytes. 211 o Associated data X is OPTIONAL. If used, it MUST have length not 212 greater than 2^(32)-1 bytes. 214 o Type y of Argon2: MUST be 0 for Argon2d, 1 for Argon2i, 2 for 215 Argon2id. 217 The Argon2 output, or "tag" is a string T bytes long. 219 3.2. Argon2 Operation 221 Argon2 uses an internal compression function G with two 1024-byte 222 inputs and a 1024-byte output, and an internal hash function H^x() 223 with x being its output length in bytes. Here H^x() applied to 224 string A is the BLAKE2b (Section 3.3) [BLAKE2] function, which takes 225 (d,ll,kk=0,nn=x) as parameters where d is A padded to a multiple of 226 128 bytes and ll is the length of d in bytes. The compression 227 function G is based on its internal permutation. A variable-length 228 hash function H' built upon H is also used. G is described in 229 Section 3.5 and H' is described in Section 3.3. 231 The Argon2 operation is as follows. 233 1. Establish H_0 as the 64-byte value as shown below. If K, X, or S 234 has zero length it is just absent but its length field remains. 236 H_0 = H^(64)(LE32(p) || LE32(T) || LE32(m) || LE32(t) || 237 LE32(v) || LE32(y) || LE32(length(P)) || P || 238 LE32(length(S)) || S || LE32(length(K)) || K || 239 LE32(length(X)) || X) 241 H_0 generation 243 2. Allocate the memory as m' 1024-byte blocks where m' is derived 244 as: 246 m' = 4 * p * floor (m / 4p) 248 Memory allocation 250 For p lanes, the memory is organized in a matrix B[i][j] of 251 blocks with p rows (lanes) and q = m' / p columns. 253 3. Compute B[i][0] for all i ranging from (and including) 0 to (not 254 including) p. 256 B[i][0] = H'^(1024)(H_0 || LE32(0) || LE32(i)) 258 Lane starting blocks 260 4. Compute B[i][1] for all i ranging from (and including) 0 to (not 261 including) p. 263 B[i][1] = H'^(1024)(H_0 || LE32(1) || LE32(i)) 265 Second lane blocks 267 5. Compute B[i][j] for all i ranging from (and including) 0 to (not 268 including) p, and for all j ranging from (and including) 2) to 269 (not including) q. The computation MUST proceed slicewise 270 (Section 3.4): first blocks from slice 0 are computed for all 271 lanes (in an arbitrary order of lanes), then blocks from slice 1 272 are computed etc. The block indices l and z are determined for 273 each i, j differently for Argon2d, Argon2i, and Argon2id. 275 B[i][j] = G(B[i][j-1], B[l][z]) 277 Further block generation 279 6. If the number of passes t is larger than 1, we repeat the steps. 280 However blocks are computed differently as the old value is XORed 281 with the new one: 283 B[i][0] = G(B[i][q-1], B[l][z]) XOR B[i][0]; 284 B[i][j] = G(B[i][j-1], B[l][z]) XOR B[i][j]. 286 Further passes 288 7. After t steps have been iterated, the final block C is computed 289 as the XOR of the last column: 291 C = B[0][q-1] XOR B[1][q-1] XOR ... XOR B[p-1][q-1] 293 Final block 295 8. The output tag is computed as H'^T(C). 297 3.3. Variable-length hash function H' 299 Let V_i be a 64-byte block, and W_i be its first 32 bytes. Then we 300 define: 302 if T <= 64 303 H'^T(A) = H^T(LE32(T)||A) 304 else 305 r = ceil(T/32)-2 306 V_1 = H^(64)(LE32(T)||A) 307 V_2 = H^(64)(V_1) 308 ... 309 V_r = H^(64)(V_{r-1}) 310 V_{r+1} = H^(T-32*r)(V_{r}) 311 H'^T(X) = W_1 || W_2 || ... || W_r || V_{r+1} 313 Function H' for tag and initial block computations 315 3.4. Indexing 317 To enable parallel block computation, we further partition the memory 318 matrix into SL = 4 vertical slices. The intersection of a slice and 319 a lane is called a segment, which has length q/SL. Segments of the 320 same slice can be computed in parallel and do not reference blocks 321 from each other. All other blocks can be referenced. 323 slice 0 slice 1 slice 2 slice 3 324 ___/\___ ___/\___ ___/\___ ___/\___ 325 / \ / \ / \ / \ 326 +----------+----------+----------+----------+ 327 | | | | | > lane 0 328 +----------+----------+----------+----------+ 329 | | | | | > lane 1 330 +----------+----------+----------+----------+ 331 | | | | | > lane 2 332 +----------+----------+----------+----------+ 333 | ... ... ... | ... 334 +----------+----------+----------+----------+ 335 | | | | | > lane p - 1 336 +----------+----------+----------+----------+ 338 Single-pass Argon2 with p lanes and 4 slices 340 3.4.1. Computing the 32-bit values J_1 and J_2 342 3.4.1.1. Argon2d 344 J_1 is given by the first 32 bits of block B[i][j-1], while J_2 is 345 given by the next 32-bits of block B[i][j-1]: 347 J_1 = int32(extract(B[i][j-1], 0)) 348 J_2 = int32(extract(B[i][j-1], 1)) 350 Deriving J1,J2 in Argon2d 352 3.4.1.2. Argon2i 354 For each segment we do the following. First we compute the value Z 355 as 357 Z= ( LE64(r) || LE64(l) || LE64(sl) || LE64(m') || 358 LE64(t) || LE64(y) ), where 360 r -- the pass number 361 l -- the lane number 362 sl -- the slice number 363 m' -- the total number of memory blocks 364 t -- the total number of passes 365 y -- the Argon2 type (0 for Argon2d, 366 1 for Argon2i, 2 for Argon2id) 368 Input to compute J1,J2 in Argon2i 370 Then we compute q/(128*SL) 1024-byte values 371 G(ZERO(1024),G(ZERO(1024), Z || LE64(1) || ZERO(968) )), 372 G(ZERO(1024),G(ZERO(1024), Z || LE64(2) || ZERO(968) )),... , 373 G(ZERO(1024),G(ZERO(1024), Z || LE64(q/(128*SL)) || ZERO(968) )), 374 which are partitioned into q/(SL) 8-byte values X, which are viewed 375 as X1||X2 and converted to J_1=int32(X1) and J_2=int32(X2). The 376 values r, l, sl, m', t, y, i are represented as 8 bytes in little- 377 endian. 379 3.4.1.3. Argon2id 381 If the pass number is 0 and the slice number is 0 or 1, then compute 382 J_1 and J_2 as for Argon2i, else compute J_1 and J_2 as for Argon2d. 384 3.4.2. Mapping J_1 and J_2 to reference block index [l][z] 386 The value of l = J_2 mod p gives the index of the lane from which the 387 block will be taken. For the first pass (r=0) and the first slice 388 (sl=0) the block is taken from the current lane. 390 The set W contains the indices that are referenced according to the 391 following rules: 393 1. If l is the current lane, then W includes the indices of all 394 blocks in the last SL - 1 = 3 segments computed and finished, as 395 well as the blocks computed in the current segment in the current 396 pass excluding B[i][j-1]. 398 2. If l is not the current lane, then W includes the indices of all 399 blocks in the last SL - 1 = 3 segments computed and finished in 400 lane l. If B[i][j] is the first block of a segment, then the 401 very last index from W is excluded. 403 Then take a block from W with a non-uniform distribution over 404 [0, |W|) using the mapping 406 J_1 -> |W|(1 - J_1^2 / 2^(64)) 408 Computing J1 410 To avoid floating point computation, the following approximation is 411 used: 413 x = J_1^2 / 2^(32) 414 y = (|W| * x) / 2^(32) 415 zz = |W| - 1 - y 417 Computing J1, part 2 419 Then take the zz-th index from W, it will be the z value for the 420 reference block index [l][z]. 422 3.5. Compression function G 424 The compression function G is built upon the BLAKE2b-based 425 transformation P. P operates on the 128-byte input, which can be 426 viewed as 8 16-byte registers: 428 P(A_0, A_1, ... ,A_7) = (B_0, B_1, ... ,B_7) 430 Blake round function P 432 The compression function G(X, Y) operates on two 1024-byte blocks X 433 and Y. It first computes R = X XOR Y. Then R is viewed as a 8x8 434 matrix of 16-byte registers R_0, R_1, ... , R_63. Then P is first 435 applied to each row, and then to each column to get Z: 437 ( Q_0, Q_1, Q_2, ... , Q_7) <- P( R_0, R_1, R_2, ... , R_7) 438 ( Q_8, Q_9, Q_10, ... , Q_15) <- P( R_8, R_9, R_10, ... , R_15) 439 ... 440 (Q_56, Q_57, Q_58, ... , Q_63) <- P(R_56, R_57, R_58, ... , R_63) 441 ( Z_0, Z_8, Z_16, ... , Z_56) <- P( Q_0, Q_8, Q_16, ... , Q_56) 442 ( Z_1, Z_9, Z_17, ... , Z_57) <- P( Q_1, Q_9, Q_17, ... , Q_57) 443 ... 444 ( Z_7, Z_15, Z 23, ... , Z_63) <- P( Q_7, Q_15, Q_23, ... , Q_63) 446 Core of compression function G 448 Finally, G outputs Z XOR R: 450 G: (X, Y) -> R -> Q -> Z -> Z XOR R 451 +---+ +---+ 452 | X | | Y | 453 +---+ +---+ 454 | | 455 ---->XOR<---- 456 --------| 457 | \ / 458 | +---+ 459 | | R | 460 | +---+ 461 | | 462 | \ / 463 | P rowwise 464 | | 465 | \ / 466 | +---+ 467 | | Q | 468 | +---+ 469 | | 470 | \ / 471 | P columnwise 472 | | 473 | \ / 474 | +---+ 475 | | Z | 476 | +---+ 477 | | 478 | \ / 479 ------>XOR 480 | 481 \ / 483 Argon2 compression function G. 485 3.6. Permutation P 487 Permutation P is based on the round function of BLAKE2b. The 8 488 16-byte inputs S_0, S_1, ... , S_7 are viewed as a 4x4 matrix of 489 64-bit words, where S_i = (v_{2*i+1} || v_{2*i}): 491 v_0 v_1 v_2 v_3 492 v_4 v_5 v_6 v_7 493 v_8 v_9 v_10 v_11 494 v_12 v_13 v_14 v_15 496 Matrix element labeling 498 It works as follows: 500 GB(v_0, v_4, v_8, v_12) 501 GB(v_1, v_5, v_9, v_13) 502 GB(v_2, v_6, v_10, v_14) 503 GB(v_3, v_7, v_11, v_15) 505 GB(v_0, v_5, v_10, v_15) 506 GB(v_1, v_6, v_11, v_12) 507 GB(v_2, v_7, v_8, v_13) 508 GB(v_3, v_4, v_9, v_14) 510 Feeding matrix elements to GB 512 GB(a, b, c, d) is defined as follows: 514 a = (a + b + 2 * trunc(a) * trunc(b)) mod 2^(64) 515 d = (d XOR a) >>> 32 516 c = (c + d + 2 * trunc(c) * trunc(d)) mod 2^(64) 517 b = (b XOR c) >>> 24 519 a = (a + b + 2 * trunc(a) * trunc(b)) mod 2^(64) 520 d = (d XOR a) >>> 16 521 c = (c + d + 2 * trunc(c) * trunc(d)) mod 2^(64) 522 b = (b XOR c) >>> 63 524 Details of GB 526 The modular additions in GB are combined with 64-bit multiplications. 527 Multiplications are the only difference to the original BLAKE2b 528 design. This choice is done to increase the circuit depth and thus 529 the running time of ASIC implementations, while having roughly the 530 same running time on CPUs thanks to parallelism and pipelining. 532 4. Parameter Choice 534 Argon2d is optimized for settings where the adversary does not get 535 regular access to system memory or CPU, i.e. he can not run side- 536 channel attacks based on the timing information, nor he can recover 537 the password much faster using garbage collection. These settings 538 are more typical for backend servers and cryptocurrency minings. For 539 practice we suggest the following settings: 541 o Cryptocurrency mining, that takes 0.1 seconds on a 2 Ghz CPU using 542 1 core -- Argon2d with 2 lanes and 250 MB of RAM. 544 Argon2id is optimized for more realistic settings, where the 545 adversary possibly can access the same machine, use its CPU or mount 546 cold-boot attacks. We suggest the following settings: 548 o Backend server authentication, that takes 0.5 seconds on a 2 GHz 549 CPU using 4 cores -- Argon2id with 8 lanes and 4 GiB of RAM. 551 o Key derivation for hard-drive encryption, that takes 3 seconds on 552 a 2 GHz CPU using 2 cores - Argon2id with 4 lanes and 6 GiB of 553 RAM. 555 o Frontend server authentication, that takes 0.5 seconds on a 2 GHz 556 CPU using 2 cores - Argon2id with 4 lanes and 1 GiB of RAM. 558 We recommend the following procedure to select the type and the 559 parameters for practical use of Argon2. 561 1. If you are OK with a uniformly safe option, but not tailored to 562 your application or hardware, select Argon2id with t=1 563 iteration, p=4 lanes and m=2^(21) (2 GiB of RAM), 128-bit salt, 564 256-bit tag size. This is the FIRST RECOMMENDED option. 566 2. If much less memory is available, a uniformly safe option is 567 Argon2id with t=3 iterations, p=4 lanes and m=2^(16) (64 MiB of 568 RAM), 128-bit salt, 256-bit tag size. This is the SECOND 569 RECOMMENDED option. 571 3. Otherwise, start with selecting the type y. If you do not know 572 the difference between them or you consider side-channel attacks 573 as viable threat, choose Argon2id. 575 4. Select p=4 lanes. 577 5. Figure out the maximum amount of memory that each call can 578 afford and translate it to the parameter m. 580 6. Figure out the maximum amount of time (in seconds) that each 581 call can afford. 583 7. Select the salt length. 128 bits is sufficient for all 584 applications, but can be reduced to 64 bits in the case of space 585 constraints. 587 8. Select the tag length. 128 bits is sufficient for most 588 applications, including key derivation. If longer keys are 589 needed, select longer tags. 591 9. If side-channel attacks are a viable threat, or if you're 592 uncertain, enable the memory wiping option in the library call. 594 10. Run the scheme of type y, memory m and p lanes, using different 595 number of passes t. Figure out the maximum t such that the 596 running time does not exceed the affordable time. If it exceeds 597 even for t = 1, reduce m accordingly. 599 11. Use Argon2 with determined values m, p, and t. 601 5. Test Vectors 603 This section contains test vectors for Argon2. 605 5.1. Argon2d Test Vectors 607 We provide test vectors with complete outputs (tags). For the 608 convenience of developers, we also provide some interim variables, 609 concretely, first and last memory blocks of each pass. 611 ======================================= 612 Argon2d version number 19 613 ======================================= 614 Memory: 32 KiB 615 Passes: 3 616 Parallelism: 4 lanes 617 Tag length: 32 bytes 618 Password[32]: 01 01 01 01 01 01 01 01 619 01 01 01 01 01 01 01 01 620 01 01 01 01 01 01 01 01 621 01 01 01 01 01 01 01 01 622 Salt[16]: 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 623 Secret[8]: 03 03 03 03 03 03 03 03 624 Associated data[12]: 04 04 04 04 04 04 04 04 04 04 04 04 625 Pre-hashing digest: b8 81 97 91 a0 35 96 60 626 bb 77 09 c8 5f a4 8f 04 627 d5 d8 2c 05 c5 f2 15 cc 628 db 88 54 91 71 7c f7 57 629 08 2c 28 b9 51 be 38 14 630 10 b5 fc 2e b7 27 40 33 631 b9 fd c7 ae 67 2b ca ac 632 5d 17 90 97 a4 af 31 09 634 After pass 0: 635 Block 0000 [ 0]: db2fea6b2c6f5c8a 636 Block 0000 [ 1]: 719413be00f82634 637 Block 0000 [ 2]: a1e3f6dd42aa25cc 638 Block 0000 [ 3]: 3ea8efd4d55ac0d1 639 ... 640 Block 0031 [124]: 28d17914aea9734c 641 Block 0031 [125]: 6a4622176522e398 642 Block 0031 [126]: 951aa08aeecb2c05 643 Block 0031 [127]: 6a6c49d2cb75d5b6 644 After pass 1: 645 Block 0000 [ 0]: d3801200410f8c0d 646 Block 0000 [ 1]: 0bf9e8a6e442ba6d 647 Block 0000 [ 2]: e2ca92fe9c541fcc 648 Block 0000 [ 3]: 6269fe6db177a388 649 ... 650 Block 0031 [124]: 9eacfcfbdb3ce0fc 651 Block 0031 [125]: 07dedaeb0aee71ac 652 Block 0031 [126]: 074435fad91548f4 653 Block 0031 [127]: 2dbfff23f31b5883 655 After pass 2: 656 Block 0000 [ 0]: 5f047b575c5ff4d2 657 Block 0000 [ 1]: f06985dbf11c91a8 658 Block 0000 [ 2]: 89efb2759f9a8964 659 Block 0000 [ 3]: 7486a73f62f9b142 660 ... 661 Block 0031 [124]: 57cfb9d20479da49 662 Block 0031 [125]: 4099654bc6607f69 663 Block 0031 [126]: f142a1126075a5c8 664 Block 0031 [127]: c341b3ca45c10da5 665 Tag: 51 2b 39 1b 6f 11 62 97 666 53 71 d3 09 19 73 42 94 667 f8 68 e3 be 39 84 f3 c1 668 a1 3a 4d b9 fa be 4a cb 670 5.2. Argon2i Test Vectors 672 ======================================= 673 Argon2i version number 19 674 ======================================= 675 Memory: 32 KiB 676 Passes: 3 677 Parallelism: 4 lanes 678 Tag length: 32 bytes 679 Password[32]: 01 01 01 01 01 01 01 01 680 01 01 01 01 01 01 01 01 681 01 01 01 01 01 01 01 01 682 01 01 01 01 01 01 01 01 683 Salt[16]: 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 684 Secret[8]: 03 03 03 03 03 03 03 03 685 Associated data[12]: 04 04 04 04 04 04 04 04 04 04 04 04 686 Pre-hashing digest: c4 60 65 81 52 76 a0 b3 687 e7 31 73 1c 90 2f 1f d8 688 0c f7 76 90 7f bb 7b 6a 689 5c a7 2e 7b 56 01 1f ee 690 ca 44 6c 86 dd 75 b9 46 691 9a 5e 68 79 de c4 b7 2d 692 08 63 fb 93 9b 98 2e 5f 693 39 7c c7 d1 64 fd da a9 695 After pass 0: 696 Block 0000 [ 0]: f8f9e84545db08f6 697 Block 0000 [ 1]: 9b073a5c87aa2d97 698 Block 0000 [ 2]: d1e868d75ca8d8e4 699 Block 0000 [ 3]: 349634174e1aebcc 700 ... 701 Block 0031 [124]: 975f596583745e30 702 Block 0031 [125]: e349bdd7edeb3092 703 Block 0031 [126]: b751a689b7a83659 704 Block 0031 [127]: c570f2ab2a86cf00 706 After pass 1: 707 Block 0000 [ 0]: b2e4ddfcf76dc85a 708 Block 0000 [ 1]: 4ffd0626c89a2327 709 Block 0000 [ 2]: 4af1440fff212980 710 Block 0000 [ 3]: 1e77299c7408505b 711 ... 712 Block 0031 [124]: e4274fd675d1e1d6 713 Block 0031 [125]: 903fffb7c4a14c98 714 Block 0031 [126]: 7e5db55def471966 715 Block 0031 [127]: 421b3c6e9555b79d 717 After pass 2: 718 Block 0000 [ 0]: af2a8bd8482c2f11 719 Block 0000 [ 1]: 785442294fa55e6d 720 Block 0000 [ 2]: 9256a768529a7f96 721 Block 0000 [ 3]: 25a1c1f5bb953766 722 ... 723 Block 0031 [124]: 68cf72fccc7112b9 724 Block 0031 [125]: 91e8c6f8bb0ad70d 725 Block 0031 [126]: 4f59c8bd65cbb765 726 Block 0031 [127]: 71e436f035f30ed0 727 Tag: c8 14 d9 d1 dc 7f 37 aa 728 13 f0 d7 7f 24 94 bd a1 729 c8 de 6b 01 6d d3 88 d2 730 99 52 a4 c4 67 2b 6c e8 732 5.3. Argon2id Test Vectors 734 ======================================= 735 Argon2id version number 19 736 ======================================= 737 Memory: 32 KiB, Passes: 3, 738 Parallelism: 4 lanes, Tag length: 32 bytes 739 Password[32]: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 740 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 741 Salt[16]: 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 02 742 Secret[8]: 03 03 03 03 03 03 03 03 743 Associated data[12]: 04 04 04 04 04 04 04 04 04 04 04 04 744 Pre-hashing digest: 28 89 de 48 7e b4 2a e5 00 c0 00 7e d9 25 2f 745 10 69 ea de c4 0d 57 65 b4 85 de 6d c2 43 7a 67 b8 54 6a 2f 0a 746 cc 1a 08 82 db 8f cf 74 71 4b 47 2e 94 df 42 1a 5d a1 11 2f fa 747 11 43 43 70 a1 e9 97 749 After pass 0: 750 Block 0000 [ 0]: 6b2e09f10671bd43 751 Block 0000 [ 1]: f69f5c27918a21be 752 Block 0000 [ 2]: dea7810ea41290e1 753 Block 0000 [ 3]: 6787f7171870f893 754 ... 755 Block 0031 [124]: 377fa81666dc7f2b 756 Block 0031 [125]: 50e586398a9c39c8 757 Block 0031 [126]: 6f732732a550924a 758 Block 0031 [127]: 81f88b28683ea8e5 760 After pass 1: 761 Block 0000 [ 0]: 3653ec9d01583df9 762 Block 0000 [ 1]: 69ef53a72d1e1fd3 763 Block 0000 [ 2]: 35635631744ab54f 764 Block 0000 [ 3]: 599512e96a37ab6e 765 ... 766 Block 0031 [124]: 4d4b435cea35caa6 767 Block 0031 [125]: c582210d99ad1359 768 Block 0031 [126]: d087971b36fd6d77 769 Block 0031 [127]: a55222a93754c692 771 After pass 2: 772 Block 0000 [ 0]: 942363968ce597a4 773 Block 0000 [ 1]: a22448c0bdad5760 774 Block 0000 [ 2]: a5f80662b6fa8748 775 Block 0000 [ 3]: a0f9b9ce392f719f 776 ... 777 Block 0031 [124]: d723359b485f509b 778 Block 0031 [125]: cb78824f42375111 779 Block 0031 [126]: 35bc8cc6e83b1875 780 Block 0031 [127]: 0b012846a40f346a 781 Tag: 0d 64 0d f5 8d 78 76 6c 08 c0 37 a3 4a 8b 53 c9 d0 782 1e f0 45 2d 75 b6 5e b5 25 20 e9 6b 01 e6 59 784 6. IANA Considerations 786 None. 788 7. Security Considerations 790 7.1. Security as hash function and KDF 792 The collision and preimage resistance levels of Argon2 are equivalent 793 to those of the underlying BLAKE2b hash function. To produce a 794 collision, 2^(256) inputs are needed. To find a preimage, 2^(512) 795 inputs must be tried. 797 The KDF security is determined by the key length and the size of the 798 internal state of hash function H'. To distinguish the output of 799 keyed Argon2 from random, minimum of (2^(128),2^length(K)) calls to 800 BLAKE2b are needed. 802 7.2. Security against time-space tradeoff attacks 804 Time-space tradeoffs allow computing a memory-hard function storing 805 fewer memory blocks at the cost of more calls to the internal 806 comression function. The advantage of tradeoff attacks is measured 807 in the reduction factor to the time-area product, where memory and 808 extra compression function cores contribute to the area, and time is 809 increased to accomodate the recomputation of missed blocks. A high 810 reduction factor may potentially speed up preimage search. 812 The best known attacks on the 1-pass and 2-pass Argon2i is the low- 813 storage attack described in [CBS16], which reduces the time-area 814 product (using the peak memory value) by the factor of 5. The best 815 attack on 3-pass and more Argon2i is [AB16] with reduction factor 816 being a function of memory size and the number of passes. For 1 817 gibibyte of memory: 3 for 3 passes, 2.5 for 4 passes, 2 for 6 passes. 818 The reduction factor grows by about 0.5 with every doubling the 819 memory size. To completely prevent time-space tradeoffs from [AB16], 820 the number of passes MUST exceed binary logarithm of memory minus 26. 821 Asymptotically, the best attack on 1-pass Argon2i is given in [BZ17] 822 with maximal advantage of the adversary upper bounded by O(m^(0.233)) 823 where m is the number of blocks. This attack is also asymptotically 824 optimal as [BZ17] also prove the upper bound on any attack of 825 O(m^(0.25)). 827 The best tradeoff attack on t-pass Argon2d is the ranking tradeoff 828 attack, which reduces the time-area product by the factor of 1.33. 830 The best attack on Argon2id can be obtained by complementing the best 831 attack on the 1-pass Argon2i with the best attack on a multi-pass 832 Argon2d. Thus the best tradeoff attack on 1-pass Argon2id is the 833 combined low-storage attack (for the first half of the memory) and 834 the ranking attack (for the second half), which bring together the 835 factor of about 2.1. The best tradeoff attack on t-pass Argon2id is 836 the ranking tradeoff attack, which reduces the time-area product by 837 the factor of 1.33. 839 7.3. Security for time-bounded defenders 841 A bottleneck in a system employing the password-hashing function is 842 often the function latency rather than memory costs. A rational 843 defender would then maximize the bruteforce costs for the attacker 844 equipped with a list of hashes, salts, and timing information, for 845 fixed computing time on the defender's machine. The attack cost 846 estimates from [AB16] imply that for Argon2i, 3 passes is almost 847 optimal for the most of reasonable memory sizes, and that for Argon2d 848 and Argon2id, 1 pass maximizes the attack costs for the constant 849 defender time. 851 7.4. Recommendations 853 The Argon2id variant with t=1 and 2GiB memory is FIRST RECOMMENDED 854 option and is suggested as a default setting for all environments. 855 This setting is secure against side-channel attacks and maximizes 856 adversarial costs on dedicated bruteforce hardware. The Argon2id 857 variant with t=3 and 64 MiB memory is SECOND RECOMMENDED option and 858 is suggested as a default setting for memory-constrained 859 environments. 861 8. Acknowledgements 863 We thank greatly the following authors who helped a lot in preparing 864 and reviewing this document: Jean-Philippe Aumasson, Samuel Neves, 865 Joel Alwen, Jeremiah Blocki, Bill Cox, Arnold Reinhold, Solar 866 Designer, Russ Housley, Stanislav Smyshlyaev, Kenny Paterson, Alexey 867 Melnikov, Gwynne Raskind. 869 9. References 871 9.1. Normative References 873 [BLAKE2] Saarinen, M-J., Ed. and J-P. Aumasson, "The BLAKE2 874 Cryptographic Hash and Message Authentication Code (MAC)", 875 RFC 7693, November 2015, 876 . 878 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 879 Requirement Levels", RFC 2119, March 1997, 880 . 882 9.2. Informative References 884 [AB15] Biryukov, A. and D. Khovratovich, "Tradeoff Cryptanalysis 885 of Memory-Hard Functions", Asiacrypt 2015, December 2015, 886 . 888 [AB16] Alwen, J. and J. Blocki, "Efficiently Computing Data- 889 Independent Memory-Hard Functions", Crypto 2016, December 890 2015, . 892 [ARGON2] Biryukov, A., Dinu, D., and D. Khovratovich, "Argon2: the 893 memory-hard function for password hashing and other 894 applications", WWW www.cryptolux.org, October 2015, 895 . 897 [ARGON2ESP] 898 Biryukov, A., Dinu, D., and D. Khovratovich, "Argon2: New 899 Generation of Memory-Hard Functions for Password Hashing 900 and Other Applications", Euro SnP 2016, March 2016, 901 . 903 [BZ17] Blocki, J. and S. Zhou, "On the Depth-Robustness and 904 Cumulative Pebbling Cost of Argon2i", TCC 2017, May 2017, 905 . 907 [CBS16] Corrigan-Gibbs, H., Boneh, D., and S. Schechter, "Balloon 908 Hashing: Provably Space-Hard Hash Functions with Data- 909 Independent Access Patterns", Asiacrypt 2016, January 910 2016, . 912 [HARD] Alwen, J. and V. Serbinenko, "High Parallel Complexity 913 Graphs and Memory-Hard Functions", STOC 2015, 2014, 914 . 916 Authors' Addresses 918 Alex Biryukov 919 University of Luxembourg 921 Email: alex.biryukov@uni.lu 922 Daniel Dinu 923 University of Luxembourg 925 Email: daniel.dinu@intel.com 927 Dmitry Khovratovich 928 ABDK Consulting 930 Email: khovratovich@gmail.com 932 Simon Josefsson 933 SJD AB 935 Email: simon@josefsson.org 936 URI: http://josefsson.org/