idnits 2.17.1 draft-josefsson-scrypt-kdf-05.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 319: '... keyLength INTEGER (1..MAX) OPTIONAL }...' RFC 2119 keyword, line 361: '... keyLength INTEGER (1..MAX) OPTIONAL...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 18, 2016) is 2862 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '16' on line 165 -- Looks like a reference, but probably isn't: '12' on line 183 -- Looks like a reference, but probably isn't: '13' on line 183 -- Looks like a reference, but probably isn't: '14' on line 183 -- Looks like a reference, but probably isn't: '10' on line 181 -- Looks like a reference, but probably isn't: '15' on line 183 -- Looks like a reference, but probably isn't: '11' on line 181 -- Looks like a reference, but probably isn't: '0' on line 397 -- Looks like a reference, but probably isn't: '1' on line 402 -- Looks like a reference, but probably isn't: '2' on line 220 -- Looks like a reference, but probably isn't: '3' on line 221 ** Obsolete normative reference: RFC 2898 (Obsoleted by RFC 8018) -- Obsolete informational reference (is this intentional?): RFC 5208 (Obsoleted by RFC 5958) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Percival 3 Internet-Draft Tarsnap 4 Intended status: Informational S. Josefsson 5 Expires: November 19, 2016 SJD AB 6 May 18, 2016 8 The scrypt Password-Based Key Derivation Function 9 draft-josefsson-scrypt-kdf-05 11 Abstract 13 This document specifies the password-based key derivation function 14 scrypt. The function derives one or more secret keys from a secret 15 string. It is based on memory-hard functions which offer added 16 protection against attacks using custom hardware. The document also 17 provides an ASN.1 schema. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on November 19, 2016. 36 Copyright Notice 38 Copyright (c) 2016 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Scrypt Parameters . . . . . . . . . . . . . . . . . . . . . . 3 55 3. The Salsa20/8 Core Function . . . . . . . . . . . . . . . . . 4 56 4. The scryptBlockMix Algorithm . . . . . . . . . . . . . . . . 4 57 5. The scryptROMix Algorithm . . . . . . . . . . . . . . . . . . 5 58 6. The scrypt Algorithm . . . . . . . . . . . . . . . . . . . . 6 59 7. ASN.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . 7 60 7.1. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . 8 61 8. Test Vectors for Salsa20/8 Core . . . . . . . . . . . . . . . 9 62 9. Test Vectors for scryptBlockMix . . . . . . . . . . . . . . . 9 63 10. Test Vectors for scryptROMix . . . . . . . . . . . . . . . . 10 64 11. Test Vectors for PBKDF2 with HMAC-SHA-256 . . . . . . . . . . 11 65 12. Test Vectors for scrypt . . . . . . . . . . . . . . . . . . . 11 66 13. Test Vectors for PKCS#8 . . . . . . . . . . . . . . . . . . . 12 67 14. Copying Conditions . . . . . . . . . . . . . . . . . . . . . 13 68 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 69 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 70 17. Security Considerations . . . . . . . . . . . . . . . . . . . 13 71 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 72 18.1. Normative References . . . . . . . . . . . . . . . . . . 14 73 18.2. Informative References . . . . . . . . . . . . . . . . . 14 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 76 1. Introduction 78 Password-based key derivation functions are used in cryptography and 79 security protocols for deriving one or more secret keys from a secret 80 value. Over the years, several password-based key derivation 81 functions have been used, including the original DES-based UNIX 82 Crypt-function, FreeBSD MD5 crypt, PKCS#5 PBKDF2 [RFC2898] (typically 83 used with SHA-1), GNU SHA-256/512 crypt [SHA2CRYPT], Windows NT LAN 84 Manager (NTLM) [NTLM] hash, and the Blowfish-based bcrypt [BCRYPT]. 85 These algorithms are all based on a cryptographic primitive combined 86 with salting and/or iteration. The iteration count is used to slow 87 down the computation, and the salt is used to make pre-computation 88 costlier. 90 All password-based key derivation functions mentioned above share the 91 same weakness against powerful attackers. Providing that the number 92 of iterations used is increased as computer systems get faster, this 93 allows legitimate users to spend a constant amount of time on key 94 derivation without losing ground to an attackers' ever-increasing 95 computing power - as long as attackers are limited to the same 96 software implementations as legitimate users. While parallelized 97 hardware implementations may not change the number of operations 98 performed compared to software implementations, this does not prevent 99 them from dramatically changing the asymptotic cost, since in many 100 contexts - including the embarrassingly parallel task of performing a 101 brute-force search for a passphrase - dollar-seconds are the most 102 appropriate units for measuring the cost of a computation. As 103 semiconductor technology develops, circuits do not merely become 104 faster; they also become smaller, allowing for a larger amount of 105 parallelism at the same cost. 107 Consequently, existing key derivation algorithms, even when the 108 iteration count is increased so that the time taken to verify a 109 password remains constant, the cost of finding a password by using a 110 brute force attack implemented in hardware drops each year. 112 The scrypt function aims to reduce the advantage which attackers can 113 gain by using custom-designed parallel circuits for breaking 114 password-based key derivation functions. 116 This document do not introduce scrypt for the first time. The 117 original scrypt paper [SCRYPT] was published as a peer-reviewed 118 scientific paper, and contains further background and discussions. 120 The purpose of this document is to serve as a stable reference for 121 IETF documents making use of scrypt. The rest of this document is 122 divided into sections that each describe parameter choices and 123 algorithm steps needed for the final "scrypt" algorithm. 125 2. Scrypt Parameters 127 The scrypt function takes several parameters. The passphrase P is 128 typically a human-chosen password. The salt is normally uniquely and 129 randomly generated [RFC4086]. The parameter r ("blockSize") specify 130 the block size. The CPU/Memory cost parameter N ("costParameter") 131 must be larger than 1, a power of 2 and less than 2^(128 * r / 8). 132 The parallelization parameter p ("parallelizationParameter"), a 133 positive integer less than or equal to ((2^32-1) * 32) / (128 * r). 134 The intended output length dkLen in octets of the derived key 135 ("keyLength"); a positive integer less than or equal to (2^32 - 1) * 136 32. 138 Users of scrypt can tune the parameters N, r, and p according to the 139 amount of memory and computing power available, the latency-bandwidth 140 product of the memory subsystem, and the amount of parallelism 141 desired. At the current time, taking r=8 and p=1 appears to yield 142 good results, but as memory latency and CPU parallelism increase it 143 is likely that the optimum values for both r and p will increase. 145 Note also that since the computations of SMix are independent, a 146 large value of p can be used to increase the computational cost of 147 scrypt without increasing the memory usage; so we can expect scrypt 148 to remain useful even if the growth rates of CPU power and memory 149 capacity diverge. 151 3. The Salsa20/8 Core Function 153 Salsa20/8 Core is a round-reduced variant of the Salsa20 Core. It is 154 a hash function from 64-octet strings to 64-octet strings. Note that 155 Salsa20/8 Core is not a cryptographic hash function since it is not 156 collision-resistant. See section 8 of [SALSA20SPEC] for its 157 specification, and [SALSA20CORE] for more information. The algorithm 158 description, in C language, is included below as a stable reference, 159 without endianness conversion and alignment. 161 #define R(a,b) (((a) << (b)) | ((a) >> (32 - (b)))) 162 void salsa20_word_specification(uint32 out[16],uint32 in[16]) 163 { 164 int i; 165 uint32 x[16]; 166 for (i = 0;i < 16;++i) x[i] = in[i]; 167 for (i = 8;i > 0;i -= 2) { 168 x[ 4] ^= R(x[ 0]+x[12], 7); x[ 8] ^= R(x[ 4]+x[ 0], 9); 169 x[12] ^= R(x[ 8]+x[ 4],13); x[ 0] ^= R(x[12]+x[ 8],18); 170 x[ 9] ^= R(x[ 5]+x[ 1], 7); x[13] ^= R(x[ 9]+x[ 5], 9); 171 x[ 1] ^= R(x[13]+x[ 9],13); x[ 5] ^= R(x[ 1]+x[13],18); 172 x[14] ^= R(x[10]+x[ 6], 7); x[ 2] ^= R(x[14]+x[10], 9); 173 x[ 6] ^= R(x[ 2]+x[14],13); x[10] ^= R(x[ 6]+x[ 2],18); 174 x[ 3] ^= R(x[15]+x[11], 7); x[ 7] ^= R(x[ 3]+x[15], 9); 175 x[11] ^= R(x[ 7]+x[ 3],13); x[15] ^= R(x[11]+x[ 7],18); 176 x[ 1] ^= R(x[ 0]+x[ 3], 7); x[ 2] ^= R(x[ 1]+x[ 0], 9); 177 x[ 3] ^= R(x[ 2]+x[ 1],13); x[ 0] ^= R(x[ 3]+x[ 2],18); 178 x[ 6] ^= R(x[ 5]+x[ 4], 7); x[ 7] ^= R(x[ 6]+x[ 5], 9); 179 x[ 4] ^= R(x[ 7]+x[ 6],13); x[ 5] ^= R(x[ 4]+x[ 7],18); 180 x[11] ^= R(x[10]+x[ 9], 7); x[ 8] ^= R(x[11]+x[10], 9); 181 x[ 9] ^= R(x[ 8]+x[11],13); x[10] ^= R(x[ 9]+x[ 8],18); 182 x[12] ^= R(x[15]+x[14], 7); x[13] ^= R(x[12]+x[15], 9); 183 x[14] ^= R(x[13]+x[12],13); x[15] ^= R(x[14]+x[13],18); 184 } 185 for (i = 0;i < 16;++i) out[i] = x[i] + in[i]; 186 } 188 4. The scryptBlockMix Algorithm 190 The scryptBlockMix algorithm is the same as the BlockMix algorithm 191 described in [SCRYPT] but with Salsa20/8 Core used as the hash 192 function H. Below, Salsa(T) corresponds to the Salsa20/8 Core 193 function applied to the octet vector T. 195 Algorithm scryptBlockMix 197 Parameters: 198 r Block size parameter. 200 Input: 201 B[0] || B[1] || ... || B[2 * r - 1] 202 Input octet string (of size 128 * r octets), 203 treated as 2 * r 64-octet blocks, 204 where each element in B is a 64-octet block. 206 Output: 207 B'[0] || B'[1] || ... || B'[2 * r - 1] 208 Output octet string. 210 Steps: 212 1. X = B[2 * r - 1] 214 2. for i = 0 to 2 * r - 1 do 215 T = X xor B[i] 216 X = Salsa (T) 217 Y[i] = X 218 end for 220 3. B' = (Y[0], Y[2], ..., Y[2 * r - 2], 221 Y[1], Y[3], ..., Y[2 * r - 1]) 223 5. The scryptROMix Algorithm 225 The scryptROMix algorithm is the same as the ROMix algorithm 226 described in [SCRYPT] but with scryptBlockMix used as the hash 227 function H and the Integerify function explained inline. 229 Algorithm scryptROMix 231 Input: 232 r Block size parameter. 233 B Input octet vector of length 128 * r octets. 234 N CPU/Memory cost parameter, must be larger than 1, 235 a power of 2 and less than 2^(128 * r / 8). 237 Output: 238 B' Output octet vector of length 128 * r octets. 240 Steps: 242 1. X = B 244 2. for i = 0 to N - 1 do 245 V[i] = X 246 X = scryptBlockMix (X) 247 end for 249 3. for i = 0 to N - 1 do 250 j = Integerify (X) mod N 251 where Integerify (B[0] ... B[2 * r - 1]) is defined 252 as the result of interpreting B[2 * r - 1] as a 253 little-endian integer. 254 T = X xor V[j] 255 X = scryptBlockMix (T) 256 end for 258 4. B' = X 260 6. The scrypt Algorithm 262 The PBKDF2-HMAC-SHA-256 function used below denote the PBKDF2 263 algorithm [RFC2898] used with HMAC-SHA-256 [RFC6234] as the PRF. The 264 HMAC-SHA-256 function generates 32 octet outputs. 266 Algorithm scrypt 268 Input: 269 P Passphrase, an octet string. 270 S Salt, an octet string. 271 N CPU/Memory cost parameter, must be larger than 1, 272 a power of 2 and less than 2^(128 * r / 8). 273 r Block size parameter. 274 p Parallelization parameter, a positive integer 275 less than or equal to ((2^32-1) * hLen) / MFLen 276 where hLen is 32 and MFlen is 128 * r. 277 dkLen Intended output length in octets of the derived 278 key; a positive integer less than or equal to 279 (2^32 - 1) * hLen where hLen is 32. 281 Output: 282 DK Derived key, of length dkLen octets. 284 Steps: 286 1. Initialize an array B consisting of p blocks of 128 * r octets each: 287 B[0] || B[1] || ... || B[p - 1] = 288 PBKDF2-HMAC-SHA256 (P, S, 1, p * 128 * r) 290 2. for i = 0 to p - 1 do 291 B[i] = scryptROMix (r, B[i], N) 292 end for 294 3. DK = PBKDF2-HMAC-SHA256 (P, B[0] || B[1] || ... || B[p - 1], 295 1, dkLen) 297 7. ASN.1 Syntax 299 This section defines ASN.1 syntax for the scrypt key derivation 300 function. This is intended to operate on the same abstraction level 301 as PKCS#5's PBKDF2. The OID id-scrypt below can be used where id- 302 PBKDF2 is used, with scrypt-params corresponding to PBKDF2-params. 303 The intended application of these definitions includes PKCS #8 and 304 other syntax for key management. 306 The object identifier id-scrypt identifies the scrypt key derivation 307 function. 309 id-scrypt OBJECT IDENTIFIER ::= {1 3 6 1 4 1 11591 4 11} 311 The parameters field associated with this OID in an 312 AlgorithmIdentifier shall have type scrypt-params: 314 scrypt-params ::= SEQUENCE { 315 salt OCTET STRING, 316 costParameter INTEGER (1..MAX), 317 blockSize INTEGER (1..MAX), 318 parallelizationParameter INTEGER (1..MAX), 319 keyLength INTEGER (1..MAX) OPTIONAL } 321 The fields of type scrypt-params have the following meanings: 323 - salt specifies the salt value. It shall be an octet string. 325 - costParameter specifies the CPU/Memory cost parameter N. 327 - blockSize specifies the block size parameter r. 329 - parallelizationParameter specifies the parallelization parameter. 331 - keyLength, an optional field, is the length in octets of the 332 derived key. The maximum key length allowed depends on the 333 implementation; it is expected that implementation profiles may 334 further constrain the bounds. This field only provides convenience; 335 the key length is not cryptographically protected. 337 To be usable in PKCS#8 [RFC5208] and Asymmetric Key Packages 338 [RFC5958] the following extension of the PBES2-KDFs type is needed. 340 PBES2-KDFs ALGORITHM-IDENTIFIER ::= 341 { {scrypt-params IDENTIFIED BY id-scrypt}, ... } 343 7.1. ASN.1 Module 345 For reference purposes, the ASN.1 syntax is presented as an ASN.1 346 module here. 348 -- scrypt ASN.1 Module 350 scrypt-0 {1 3 6 1 4 1 11591 4 10} 352 DEFINITIONS ::= BEGIN 354 id-scrypt OBJECT IDENTIFIER ::= {1 3 6 1 4 1 11591 4 11} 356 scrypt-params ::= SEQUENCE { 357 salt OCTET STRING, 358 costParameter INTEGER (1..MAX), 359 blockSize INTEGER (1..MAX), 360 parallelizationParameter INTEGER (1..MAX), 361 keyLength INTEGER (1..MAX) OPTIONAL 362 } 364 PBES2-KDFs ALGORITHM-IDENTIFIER ::= 365 { {scrypt-params IDENTIFIED BY id-scrypt}, ... } 367 END 369 8. Test Vectors for Salsa20/8 Core 371 Below is a sequence of octets to illustrate input and output values 372 for the Salsa20/8 Core. The octets are hex encoded and whitespace is 373 inserted for readability. The value corresponds to the first input 374 and output pair generated by the first scrypt test vector below. 376 INPUT: 377 7e 87 9a 21 4f 3e c9 86 7c a9 40 e6 41 71 8f 26 378 ba ee 55 5b 8c 61 c1 b5 0d f8 46 11 6d cd 3b 1d 379 ee 24 f3 19 df 9b 3d 85 14 12 1e 4b 5a c5 aa 32 380 76 02 1d 29 09 c7 48 29 ed eb c6 8d b8 b8 c2 5e 382 OUTPUT: 383 a4 1f 85 9c 66 08 cc 99 3b 81 ca cb 02 0c ef 05 384 04 4b 21 81 a2 fd 33 7d fd 7b 1c 63 96 68 2f 29 385 b4 39 31 68 e3 c9 e6 bc fe 6b c5 b7 a0 6d 96 ba 386 e4 24 cc 10 2c 91 74 5c 24 ad 67 3d c7 61 8f 81 388 9. Test Vectors for scryptBlockMix 390 Below is a sequence of octets to illustrate input and output values 391 for scryptBlockMix. The test vector uses an r value of 1. The 392 octets are hex encoded and whitespace is inserted for readability. 393 The value corresponds to the first input and output pair generated by 394 the first scrypt test vector below. 396 INPUT 397 B[0] = f7 ce 0b 65 3d 2d 72 a4 10 8c f5 ab e9 12 ff dd 398 77 76 16 db bb 27 a7 0e 82 04 f3 ae 2d 0f 6f ad 399 89 f6 8f 48 11 d1 e8 7b cc 3b d7 40 0a 9f fd 29 400 09 4f 01 84 63 95 74 f3 9a e5 a1 31 52 17 bc d7 402 B[1] = 89 49 91 44 72 13 bb 22 6c 25 b5 4d a8 63 70 fb 403 cd 98 43 80 37 46 66 bb 8f fc b5 bf 40 c2 54 b0 404 67 d2 7c 51 ce 4a d5 fe d8 29 c9 0b 50 5a 57 1b 405 7f 4d 1c ad 6a 52 3c da 77 0e 67 bc ea af 7e 89 407 OUTPUT 408 B'[0] = a4 1f 85 9c 66 08 cc 99 3b 81 ca cb 02 0c ef 05 409 04 4b 21 81 a2 fd 33 7d fd 7b 1c 63 96 68 2f 29 410 b4 39 31 68 e3 c9 e6 bc fe 6b c5 b7 a0 6d 96 ba 411 e4 24 cc 10 2c 91 74 5c 24 ad 67 3d c7 61 8f 81 413 B'[1] = 20 ed c9 75 32 38 81 a8 05 40 f6 4c 16 2d cd 3c 414 21 07 7c fe 5f 8d 5f e2 b1 a4 16 8f 95 36 78 b7 415 7d 3b 3d 80 3b 60 e4 ab 92 09 96 e5 9b 4d 53 b6 416 5d 2a 22 58 77 d5 ed f5 84 2c b9 f1 4e ef e4 25 418 10. Test Vectors for scryptROMix 420 Below is a sequence of octets to illustrate input and output values 421 for scryptROMix. The test vector uses an r value of 1 and an N value 422 of 16. The octets are hex encoded and whitespace is inserted for 423 readability. The value corresponds to the first input and output 424 pair generated by the first scrypt test vector below. 426 INPUT: 427 B = f7 ce 0b 65 3d 2d 72 a4 10 8c f5 ab e9 12 ff dd 428 77 76 16 db bb 27 a7 0e 82 04 f3 ae 2d 0f 6f ad 429 89 f6 8f 48 11 d1 e8 7b cc 3b d7 40 0a 9f fd 29 430 09 4f 01 84 63 95 74 f3 9a e5 a1 31 52 17 bc d7 431 89 49 91 44 72 13 bb 22 6c 25 b5 4d a8 63 70 fb 432 cd 98 43 80 37 46 66 bb 8f fc b5 bf 40 c2 54 b0 433 67 d2 7c 51 ce 4a d5 fe d8 29 c9 0b 50 5a 57 1b 434 7f 4d 1c ad 6a 52 3c da 77 0e 67 bc ea af 7e 89 436 OUTPUT: 437 B = 79 cc c1 93 62 9d eb ca 04 7f 0b 70 60 4b f6 b6 438 2c e3 dd 4a 96 26 e3 55 fa fc 61 98 e6 ea 2b 46 439 d5 84 13 67 3b 99 b0 29 d6 65 c3 57 60 1f b4 26 440 a0 b2 f4 bb a2 00 ee 9f 0a 43 d1 9b 57 1a 9c 71 441 ef 11 42 e6 5d 5a 26 6f dd ca 83 2c e5 9f aa 7c 442 ac 0b 9c f1 be 2b ff ca 30 0d 01 ee 38 76 19 c4 443 ae 12 fd 44 38 f2 03 a0 e4 e1 c4 7e c3 14 86 1f 444 4e 90 87 cb 33 39 6a 68 73 e8 f9 d2 53 9a 4b 8e 446 11. Test Vectors for PBKDF2 with HMAC-SHA-256 448 Below is a sequence of octets illustring input and output values for 449 PBKDF2-HMAC-SHA-256. The octets are hex encoded and whitespace is 450 inserted for readability. The test vectors below can be used to 451 verify the PBKDF2-HMAC-SHA-256 [RFC2898] function. The password and 452 salt strings are passed as sequences of ASCII [RFC0020] octets. 454 PBKDF2-HMAC-SHA-256 (P="passwd", S="salt", 455 c=1, dkLen=64) = 456 55 ac 04 6e 56 e3 08 9f ec 16 91 c2 25 44 b6 05 457 f9 41 85 21 6d de 04 65 e6 8b 9d 57 c2 0d ac bc 458 49 ca 9c cc f1 79 b6 45 99 16 64 b3 9d 77 ef 31 459 7c 71 b8 45 b1 e3 0b d5 09 11 20 41 d3 a1 97 83 461 PBKDF2-HMAC-SHA-256 (P="Password", S="NaCl", 462 c=80000, dkLen=64) = 463 4d dc d8 f6 0b 98 be 21 83 0c ee 5e f2 27 01 f9 464 64 1a 44 18 d0 4c 04 14 ae ff 08 87 6b 34 ab 56 465 a1 d4 25 a1 22 58 33 54 9a db 84 1b 51 c9 b3 17 466 6a 27 2b de bb a1 d0 78 47 8f 62 b3 97 f3 3c 8d 468 12. Test Vectors for scrypt 470 For reference purposes, we provide the following test vectors for 471 scrypt, where the password and salt strings are passed as sequences 472 of ASCII [RFC0020] octets. 474 The parameters to the scrypt function below are, in order, the 475 password P (octet string), the salt S (octet string), the CPU/Memory 476 cost parameter N, the block size parameter r, and the parallelization 477 parameter p, and the output size dkLen. The output is hex encoded 478 and whitespace is inserted for readability. 480 scrypt (P="", S="", 481 N=16, r=1, p=1, dklen=64) = 482 77 d6 57 62 38 65 7b 20 3b 19 ca 42 c1 8a 04 97 483 f1 6b 48 44 e3 07 4a e8 df df fa 3f ed e2 14 42 484 fc d0 06 9d ed 09 48 f8 32 6a 75 3a 0f c8 1f 17 485 e8 d3 e0 fb 2e 0d 36 28 cf 35 e2 0c 38 d1 89 06 487 scrypt (P="password", S="NaCl", 488 N=1024, r=8, p=16, dkLen=64) = 489 fd ba be 1c 9d 34 72 00 78 56 e7 19 0d 01 e9 fe 490 7c 6a d7 cb c8 23 78 30 e7 73 76 63 4b 37 31 62 491 2e af 30 d9 2e 22 a3 88 6f f1 09 27 9d 98 30 da 492 c7 27 af b9 4a 83 ee 6d 83 60 cb df a2 cc 06 40 494 scrypt (P="pleaseletmein", S="SodiumChloride", 495 N=16384, r=8, p=1, dkLen=64) = 496 70 23 bd cb 3a fd 73 48 46 1c 06 cd 81 fd 38 eb 497 fd a8 fb ba 90 4f 8e 3e a9 b5 43 f6 54 5d a1 f2 498 d5 43 29 55 61 3f 0f cf 62 d4 97 05 24 2a 9a f9 499 e6 1e 85 dc 0d 65 1e 40 df cf 01 7b 45 57 58 87 501 scrypt (P="pleaseletmein", S="SodiumChloride", 502 N=1048576, r=8, p=1, dkLen=64) = 503 21 01 cb 9b 6a 51 1a ae ad db be 09 cf 70 f8 81 504 ec 56 8d 57 4a 2f fd 4d ab e5 ee 98 20 ad aa 47 505 8e 56 fd 8f 4b a5 d0 9f fa 1c 6d 92 7c 40 f4 c3 506 37 30 40 49 e8 a9 52 fb cb f4 5c 6f a7 7a 41 a4 508 13. Test Vectors for PKCS#8 510 PKCS#8 [RFC5208] and Asymmetric Key Packages [RFC5958] encode 511 encrypted private-keys. Using PBES2 with scrypt as the KDF, the 512 following illustrates an example of a PKCS#8 encoded private-key. 513 The password is "Rabbit" (without the quotes) with N=1048576, r=8 and 514 p=1. The salt is "Mouse" and the encryption algorithm used is 515 aes256-CBC. The derived key is: E2 77 EA 2C AC B2 3E DA-FC 03 9D 22 516 9B 79 DC 13 EC ED B6 01 D9 9B 18 2A-9F ED BA 1E 2B FB 4F 58. 518 -----BEGIN ENCRYPTED PRIVATE KEY----- 519 MIHiME0GCSqGSIb3DQEFDTBAMB8GCSsGAQQB2kcECzASBAVNb3VzZQIDEAAAAgEI 520 AgEBMB0GCWCGSAFlAwQBKgQQyYmguHMsOwzGMPoyObk/JgSBkJb47EWd5iAqJlyy 521 +ni5ftd6gZgOPaLQClL7mEZc2KQay0VhjZm/7MbBUNbqOAXNM6OGebXxVp6sHUAL 522 iBGY/Dls7B1TsWeGObE0sS1MXEpuREuloZjcsNVcNXWPlLdZtkSH6uwWzR0PyG/Z 523 +ZXfNodZtd/voKlvLOw5B3opGIFaLkbtLZQwMiGtl42AS89lZg== 524 -----END ENCRYPTED PRIVATE KEY----- 526 14. Copying Conditions 528 The authors agree to grant third parties the irrevocable right to 529 copy, use and distribute this entire document or any portion of it, 530 with or without modification, in any medium, without royalty, 531 provided that, unless separate permission is granted, redistributed 532 modified works do not contain misleading author, version, name of 533 work, or endorsement information. 535 15. Acknowledgements 537 Text in this document was borrowed from [SCRYPT] and [RFC2898]. The 538 PKCS#8 test vector was provided by Stephen N. Henson. 540 Feedback on this document were received from Dmitry Chestnykh, 541 Alexander Klink, Rob Kendrick, Royce Williams Ted Rolle, Jr., Eitan 542 Adler, Stephen Farrel, Nikos Mavrogiannopoulos, and Paul Kyzivat. 544 16. IANA Considerations 546 None. 548 17. Security Considerations 550 This document specifies a cryptographic algorithm, and there is 551 always a risk that someone will find a weakness in it. By following 552 the cryptographic research area you may learn of publications 553 relevant to scrypt. 555 ROMix has been proven sequential memory-hard under the Random Oracle 556 model for the hash function. The security of scrypt relies on the 557 assumption that BlockMix with Salsa20/8 Core does not exhibit any 558 "shortcuts" which would allow it to be iterated more easily than a 559 random oracle. For other claims about the security properties see 560 [SCRYPT]. 562 Passwords and other sensitive data, such as intermediate values, may 563 continue to be stored in memory, core dumps, swap areas, etc, for a 564 long time after the implementation has processed them. This makes 565 attacks on the implementation easier. Thus, implementation should 566 consider storing sensitive data in protected memory areas. How to 567 achieve this is system dependent. 569 By nature and depending on parameters, running the scrypt algorithm 570 may require large amounts of memory. Systems should protect against 571 a denial of service attack resulting from attackers presenting 572 unreasonably large parameters. 574 Poor parameter choices can be harmful for security; for example, if 575 you tune the parameters so that memory use is reduced to small 576 amounts that will affect the properties of the algorithm. 578 18. References 580 18.1. Normative References 582 [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography 583 Specification Version 2.0", RFC 2898, 584 DOI 10.17487/RFC2898, September 2000, 585 . 587 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 588 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 589 DOI 10.17487/RFC6234, May 2011, 590 . 592 18.2. Informative References 594 [RFC0020] Cerf, V., "ASCII format for network interchange", STD 80, 595 RFC 20, DOI 10.17487/RFC0020, October 1969, 596 . 598 [RFC5208] Kaliski, B., "Public-Key Cryptography Standards (PKCS) #8: 599 Private-Key Information Syntax Specification Version 1.2", 600 RFC 5208, DOI 10.17487/RFC5208, May 2008, 601 . 603 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, 604 DOI 10.17487/RFC5958, August 2010, 605 . 607 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 608 "Randomness Requirements for Security", BCP 106, RFC 4086, 609 DOI 10.17487/RFC4086, June 2005, 610 . 612 [SALSA20SPEC] 613 Bernstein, D., "Salsa20 specification", 614 WWW http://cr.yp.to/snuffle/spec.pdf, April 2005. 616 [SALSA20CORE] 617 Bernstein, D., "The Salsa20 Core", 618 WWW http://cr.yp.to/salsa20.html, March 2005. 620 [SCRYPT] Percival, C., "Stronger key derivation via sequential 621 memory-hard functions", 622 BSDCan'09 http://www.tarsnap.com/scrypt/scrypt.pdf, May 623 2009. 625 [BCRYPT] Provos, N. and D. Mazieres, "A Future-Adaptable Password 626 Scheme", USENIX 1999 627 https://www.usenix.org/legacy/event/usenix99/provos/ 628 provos.pdf, June 1999. 630 [NTLM] "[MS-NLMP]: NT LAN Manager (NTLM) Authentication 631 Protocol", Microsoft https://msdn.microsoft.com/en- 632 us/library/cc236621.aspx, 2015. 634 [SHA2CRYPT] 635 Drepper, U., "Unix crypt using SHA-256 and SHA-512", 636 URL http://www.akkadia.org/drepper/SHA-crypt.txt, April 637 2008. 639 Authors' Addresses 641 Colin Percival 642 Tarsnap 644 Email: cperciva@tarsnap.com 646 Simon Josefsson 647 SJD AB 649 Email: simon@josefsson.org 650 URI: http://josefsson.org/