idnits 2.17.1 draft-josefsson-scrypt-kdf-00.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 : ---------------------------------------------------------------------------- ** 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 281: '... keyLength INTEGER (1..MAX) OPTIONAL }...' RFC 2119 keyword, line 317: '... 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 (September 17, 2012) is 4231 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 128 -- Looks like a reference, but probably isn't: '12' on line 146 -- Looks like a reference, but probably isn't: '13' on line 146 -- Looks like a reference, but probably isn't: '14' on line 146 -- Looks like a reference, but probably isn't: '10' on line 144 -- Looks like a reference, but probably isn't: '15' on line 146 -- Looks like a reference, but probably isn't: '11' on line 144 -- Looks like a reference, but probably isn't: '0' on line 348 -- Looks like a reference, but probably isn't: '2' on line 182 -- Looks like a reference, but probably isn't: '1' on line 353 -- Looks like a reference, but probably isn't: '3' on line 183 ** Obsolete normative reference: RFC 2898 (Obsoleted by RFC 8018) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 13 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: March 21, 2013 SJD AB 6 September 17, 2012 8 The scrypt Password-Based Key Derivation Function 9 draft-josefsson-scrypt-kdf-00 11 Abstract 13 This document specify the password-based key derivation function 14 scrypt. The function is used to derive one or more secret keys from 15 a secret string. It is based on memory-hard functions which offers 16 some added protection against attacks using custom hardware. The 17 document also provide 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 March 21, 2013. 36 Copyright Notice 38 Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. The Salsa20/8 core Function . . . . . . . . . . . . . . . . . 3 55 3. The scryptBlockMix Algorithm . . . . . . . . . . . . . . . . . 4 56 4. The scryptROMix Algorithm . . . . . . . . . . . . . . . . . . 5 57 5. The scrypt Algorithm . . . . . . . . . . . . . . . . . . . . . 6 58 6. ASN.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 7 59 6.1. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . . 8 60 7. Test Vectors for Salsa20/8 core . . . . . . . . . . . . . . . 9 61 8. Test Vectors for scryptBlockMix . . . . . . . . . . . . . . . 9 62 9. Test Vectors for scryptROMix . . . . . . . . . . . . . . . . . 10 63 10. Test Vectors for PBKDF2 with HMAC-SHA-256 . . . . . . . . . . 10 64 11. Test Vectors for scrypt . . . . . . . . . . . . . . . . . . . 11 65 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 66 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 67 14. Security Considerations . . . . . . . . . . . . . . . . . . . 12 68 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 69 15.1. Normative References . . . . . . . . . . . . . . . . . . . 12 70 15.2. Informative References . . . . . . . . . . . . . . . . . . 12 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 73 1. Introduction 75 Password-based key derivation functions are used in cryptography for 76 deriving one or more secret keys from a secret value. Over the 77 years, several password-based key derivation functions have been 78 used, including the original DES-based UNIX Crypt-function, FreeBSD 79 MD5 crypt, PKCS#5 PBKDF2 [RFC2898] (typically used with SHA-1), GNU 80 SHA-256/512 crypt, Windows NT LAN Manager (NTLM) hash, and Blowfish- 81 based bcrypt. These algorithms are based on similar techniques that 82 employ a cryptographic primitive, salting and/or iteration. The 83 iteration count is used to slow down the computation. 85 Providing that the number of iterations used is increased as computer 86 systems get faster, this allows legitimate users to spend a constant 87 amount of time on key derivation without losing ground to attackers' 88 ever-increasing computing power - as long as attackers are limited to 89 the same software implementations as legitimate users. However, as 90 Bernstein famously pointed out in the context of integer 91 factorization, while parallelized hardware implementations may not 92 change the number of operations performed compared to software 93 implementations, this does not prevent them from dramatically 94 changing the asymptotic cost, since in many contexts - including the 95 embarrassingly parallel task of performing a brute-force search for a 96 passphrase - dollar-seconds are the most appropriate units for 97 measuring the cost of a computation. As semiconductor technology 98 develops, circuits do not merely become faster; they also become 99 smaller, allowing for a larger amount of parallelism at the same 100 cost. Consequently, using existing key derivation algorithms, even 101 if the iteration count is increased such that the time taken to 102 verify a password remains constant, the cost of finding a password by 103 using a brute force attack implemented in hardware drops each year. 105 The scrypt function aims to reduce the advantage which attackers can 106 gain by using custom-designed parallel circuits for breaking 107 password-based key derivation functions. 109 For further background, see the original scrypt paper [SCRYPT]. 111 The rest of this document is divided into sections that each describe 112 algorithms needed for the final "scrypt" algorithm. 114 2. The Salsa20/8 core Function 116 Salsa20/8 core is a round-reduced variant of the Salsa20 core. It is 117 a hash function from 64-octet strings to 64-octet strings. Note that 118 these functions are not cryptographic hash function since they are 119 not collision-resistant. See [SALSA20CORE] for the specification. 121 Below is reference code for the Salsa20/8 core function, for 122 illustration. 124 #define R(a,b) (((a) << (b)) | ((a) >> (32 - (b)))) 125 void salsa208_word_specification(uint32 out[16],uint32 in[16]) 126 { 127 int i; 128 uint32 x[16]; 129 for (i = 0;i < 16;++i) x[i] = in[i]; 130 for (i = 8;i > 0;i -= 2) { 131 x[ 4] ^= R(x[ 0]+x[12], 7); x[ 8] ^= R(x[ 4]+x[ 0], 9); 132 x[12] ^= R(x[ 8]+x[ 4],13); x[ 0] ^= R(x[12]+x[ 8],18); 133 x[ 9] ^= R(x[ 5]+x[ 1], 7); x[13] ^= R(x[ 9]+x[ 5], 9); 134 x[ 1] ^= R(x[13]+x[ 9],13); x[ 5] ^= R(x[ 1]+x[13],18); 135 x[14] ^= R(x[10]+x[ 6], 7); x[ 2] ^= R(x[14]+x[10], 9); 136 x[ 6] ^= R(x[ 2]+x[14],13); x[10] ^= R(x[ 6]+x[ 2],18); 137 x[ 3] ^= R(x[15]+x[11], 7); x[ 7] ^= R(x[ 3]+x[15], 9); 138 x[11] ^= R(x[ 7]+x[ 3],13); x[15] ^= R(x[11]+x[ 7],18); 139 x[ 1] ^= R(x[ 0]+x[ 3], 7); x[ 2] ^= R(x[ 1]+x[ 0], 9); 140 x[ 3] ^= R(x[ 2]+x[ 1],13); x[ 0] ^= R(x[ 3]+x[ 2],18); 141 x[ 6] ^= R(x[ 5]+x[ 4], 7); x[ 7] ^= R(x[ 6]+x[ 5], 9); 142 x[ 4] ^= R(x[ 7]+x[ 6],13); x[ 5] ^= R(x[ 4]+x[ 7],18); 143 x[11] ^= R(x[10]+x[ 9], 7); x[ 8] ^= R(x[11]+x[10], 9); 144 x[ 9] ^= R(x[ 8]+x[11],13); x[10] ^= R(x[ 9]+x[ 8],18); 145 x[12] ^= R(x[15]+x[14], 7); x[13] ^= R(x[12]+x[15], 9); 146 x[14] ^= R(x[13]+x[12],13); x[15] ^= R(x[14]+x[13],18); 147 } 148 for (i = 0;i < 16;++i) out[i] = x[i] + in[i]; 149 } 151 3. The scryptBlockMix Algorithm 153 We now describe the scryptBlockMix algorithm. scryptBlockMix is the 154 same as the BlockMix function described in [SCRYPT] but with the 155 Salsa20/8 core function used as the hash function H. Below, Salsa(T) 156 corresponds to the Salsa20/8 core function applied to the octet 157 vector T. 159 Algorithm scryptBlockMix 161 Parameters: 162 r Block size parameter. 164 Input: 165 B[0], ..., B[2 * r - 1] 166 Input vector of 2 * r 64-octet blocks. 168 Output: 169 B'[0], ..., B'[2 * r - 1] 170 Output vector of 2 * r 64-octet blocks. 172 Steps: 174 1. X = B[2 * r - 1] 176 2. for i = 0 to 2 * r - 1 do 177 T = X xor B[i] 178 X = Salsa (T) 179 Y[i] = X 180 end for 182 3. B' = (Y[0], Y[2], ..., Y[2 * r - 2], 183 Y[1], Y[3], ..., Y[2 * r - 1]) 185 4. The scryptROMix Algorithm 187 We now describe the scryptROMix algorithm. scryptROMix is the same as 188 the ROMix function described in [SCRYPT] but with the scryptBlockMix 189 algorithm used as the hash function H and the Integerify function 190 explained inline. 192 Algorithm scryptROMix 194 Input: 195 r Block size parameter. 196 B Input octet vector of length 128 * r octets. 197 N CPU/Memory cost parameter, must be larger than 1, 198 a power of 2 and less than 2^(128 * r / 8). 200 Output: 201 B' Output octet vector of length 128 * r octets. 203 Steps: 205 1. X = B 207 2. for i = 0 to N - 1 do 208 V[i] = X 209 X = scryptBlockMix (X) 210 end for 212 3. for i = 0 to N - 1 do 213 j = Integerify (X) mod N 214 where Integerify (B[0] ... B[2 * r - 1]) is defined 215 as the result of interpreting B[2 * r - 1] as a 216 little-endian integer. 217 T = X xor V[j] 218 X = scryptBlockMix (T) 219 end for 221 4. B' = X 223 5. The scrypt Algorithm 225 We now describe the scrypt algorithm. 227 The PBKDF2-HMAC-SHA-256 function used below denote the PBKDF2 228 algorithm [RFC2898] used with HMAC-SHA-256 [RFC6234] as the PRF. The 229 HMAC-SHA-256 function generates 32 octet outputs. 231 Algorithm scrypt 233 Input: 234 P Passphrase, an octet string. 235 S Salt, an octet string. 236 r Block size parameter. 237 N CPU/Memory cost parameter, must be larger than 1, 238 a power of 2 and less than 2^(128 * r / 8). 239 p Parallelization parameter, a positive integer 240 less than or equal to ((2^32-1) * hLen) / MFLen 241 where hLen is 32 and MFlen is 128 * r. 242 dkLen Intended output length in octets of the derived 243 key; a positive integer less than or equal to 244 (2^32 - 1) * hLen where hLen is 32. 246 Output: 247 DK Derived key, of length dkLen octets. 249 Steps: 251 1. B[0] || B[1] || ... || B[p - 1] = 252 PBKDF2-HMAC-SHA256 (P, S, 1, p * 128 * r) 254 2. for i = 0 to p - 1 do 255 B[i] = scryptROMix (r, B[i], N) 256 end for 258 3. DK = PBKDF2-HMAC-SHA256 (P, B[0] || B[1] || ... || B[p - 1], 259 1, dkLen) 261 6. ASN.1 Syntax 263 This section defines ASN.1 syntax for the scrypt key derivation 264 function. The intended application of these definitions includes 265 PKCS #8 and other syntax for key management. (Various aspects of 266 ASN.1 are specified in several ISO/IEC standards.) 268 The object identifier id-scrypt identifies the scrypt key derivation 269 function. 271 id-scrypt OBJECT IDENTIFIER ::= {1 3 6 1 4 1 11591 4 11} 273 The parameters field associated with this OID in an 274 AlgorithmIdentifier shall have type scrypt-params: 276 scrypt-params ::= SEQUENCE { 277 salt OCTET STRING, 278 blockSize INTEGER (1..MAX), 279 costParameter INTEGER (1..MAX), 280 parallelizationParameter INTEGER (1..MAX), 281 keyLength INTEGER (1..MAX) OPTIONAL } 283 The fields of type scrypt-params have the following meanings: 285 - salt specifies the salt value. It shall be an octet string. 287 - blockSize specifies the block size parameter r. 289 - costParameter specifies the CPU/Memory cost parameter. 291 - parallelizationParameter specifies the parallelization parameter. 293 - keyLength, an optional field, is the length in octets of the 294 derived key. The maximum key length allowed depends on the 295 implementation; it is expected that implementation profiles may 296 further constrain the bounds. The field is provided for convenience 297 only; the key length is not cryptographically protected. 299 6.1. ASN.1 Module 301 For reference purposes, the ASN.1 syntax is presented as an ASN.1 302 module here. 304 -- scrypt ASN.1 Module 306 scrypt-0 {1 3 6 1 4 1 11591 4 10} 308 DEFINITIONS ::= BEGIN 310 id-scrypt OBJECT IDENTIFIER ::= {1 3 6 1 4 1 11591 4 11} 312 scrypt-params ::= SEQUENCE { 313 salt OCTET STRING, 314 blockSize INTEGER (1..MAX), 315 costParameter INTEGER (1..MAX), 316 parallelizationParameter INTEGER (1..MAX), 317 keyLength INTEGER (1..MAX) OPTIONAL 318 } 320 END 322 7. Test Vectors for Salsa20/8 core 324 The value is hex encoded and whitespace is inserted for readability. 325 The value correspond to the first input and output pair generated by 326 the first scrypt test vector below. 328 INPUT: 329 7e879a21 4f3ec986 7ca940e6 41718f26 330 baee555b 8c61c1b5 0df84611 6dcd3b1d 331 ee24f319 df9b3d85 14121e4b 5ac5aa32 332 76021d29 09c74829 edebc68d b8b8c25e 334 OUTPUT: 335 a41f859c 6608cc99 3b81cacb 020cef05 336 044b2181 a2fd337d fd7b1c63 96682f29 337 b4393168 e3c9e6bc fe6bc5b7 a06d96ba 338 e424cc10 2c91745c 24ad673d c7618f81 340 8. Test Vectors for scryptBlockMix 342 The following test vector use a r value of 1. The value is hex 343 encoded and whitespace is inserted for readability. The value 344 correspond to the first input and output pair generated by the first 345 scrypt test vector below. 347 INPUT 348 B[0] = f7ce0b65 3d2d72a4 108cf5ab e912ffdd 349 777616db bb27a70e 8204f3ae 2d0f6fad 350 89f68f48 11d1e87b cc3bd740 0a9ffd29 351 094f0184 639574f3 9ae5a131 5217bcd7 353 B[1] = 89499144 7213bb22 6c25b54d a86370fb 354 cd984380 374666bb 8ffcb5bf 40c254b0 355 67d27c51 ce4ad5fe d829c90b 505a571b 356 7f4d1cad 6a523cda 770e67bc eaaf7e89 358 OUTPUT 359 B'[0] = a41f859c 6608cc99 3b81cacb 020cef05 360 044b2181 a2fd337d fd7b1c63 96682f29 361 b4393168 e3c9e6bc fe6bc5b7 a06d96ba 362 e424cc10 2c91745c 24ad673d c7618f81 364 B'[1] = 20edc975 323881a8 0540f64c 162dcd3c 365 21077cfe 5f8d5fe2 b1a4168f 953678b7 366 7d3b3d80 3b60e4ab 920996e5 9b4d53b6 367 5d2a2258 77d5edf5 842cb9f1 4eefe425 369 9. Test Vectors for scryptROMix 371 The following test vector use a r value of 1 and N value of 16. The 372 value is hex encoded and whitespace is inserted for readability. The 373 value correspond to the first input and output pair generated by the 374 first scrypt test vector below. 376 INPUT: 377 B = f7ce0b65 3d2d72a4 108cf5ab e912ffdd 378 777616db bb27a70e 8204f3ae 2d0f6fad 379 89f68f48 11d1e87b cc3bd740 0a9ffd29 380 094f0184 639574f3 9ae5a131 5217bcd7 381 89499144 7213bb22 6c25b54d a86370fb 382 cd984380 374666bb 8ffcb5bf 40c254b0 383 67d27c51 ce4ad5fe d829c90b 505a571b 384 7f4d1cad 6a523cda 770e67bc eaaf7e89 386 OUTPUT: 387 B = 79ccc193 629debca 047f0b70 604bf6b6 388 2ce3dd4a 9626e355 fafc6198 e6ea2b46 389 d5841367 3b99b029 d665c357 601fb426 390 a0b2f4bb a200ee9f 0a43d19b 571a9c71 391 ef1142e6 5d5a266f ddca832c e59faa7c 392 ac0b9cf1 be2bffca 300d01ee 387619c4 393 ae12fd44 38f203a0 e4e1c47e c314861f 394 4e9087cb 33396a68 73e8f9d2 539a4b8e 396 10. Test Vectors for PBKDF2 with HMAC-SHA-256 398 The test vectors below can be used to verify the PBKDF2-HMAC-SHA-256 399 [RFC2898] function. The password and salt strings are passed as 400 sequences of ASCII [ANSI.X3-4.1986] octets. 402 PBKDF2-HMAC-SHA-256 (P="passwd", S="salt", 403 c=1, dkLen=64) = 404 55 ac 04 6e 56 e3 08 9f ec 16 91 c2 25 44 b6 05 405 f9 41 85 21 6d de 04 65 e6 8b 9d 57 c2 0d ac bc 406 49 ca 9c cc f1 79 b6 45 99 16 64 b3 9d 77 ef 31 407 7c 71 b8 45 b1 e3 0b d5 09 11 20 41 d3 a1 97 83 409 PBKDF2-HMAC-SHA-256 (P="Password", S="NaCl", 410 c=80000, dkLen=64) = 411 4d dc d8 f6 0b 98 be 21 83 0c ee 5e f2 27 01 f9 412 64 1a 44 18 d0 4c 04 14 ae ff 08 87 6b 34 ab 56 413 a1 d4 25 a1 22 58 33 54 9a db 84 1b 51 c9 b3 17 414 6a 27 2b de bb a1 d0 78 47 8f 62 b3 97 f3 3c 8d 416 11. Test Vectors for scrypt 418 For reference purposes, we provide the following test vectors for 419 scrypt, where the password and salt strings are passed as sequences 420 of ASCII [ANSI.X3-4.1986] octets. 422 The parameters to the scrypt function below are, in order, the 423 password (octet string), the salt (octet string), the CPU/Memory cost 424 parameter N, the block size parameter r, and the parallelization 425 parameter p, and the output size dkLen. The output is hex encoded 426 and whitespace is inserted for readability. 428 scrypt (P="", S="", 429 r=16, N=1, p=1, dklen=64) = 430 77 d6 57 62 38 65 7b 20 3b 19 ca 42 c1 8a 04 97 431 f1 6b 48 44 e3 07 4a e8 df df fa 3f ed e2 14 42 432 fc d0 06 9d ed 09 48 f8 32 6a 75 3a 0f c8 1f 17 433 e8 d3 e0 fb 2e 0d 36 28 cf 35 e2 0c 38 d1 89 06 435 scrypt (P="password", S="NaCl", 436 r=1024, N=8, p=16, dkLen=64) = 437 fd ba be 1c 9d 34 72 00 78 56 e7 19 0d 01 e9 fe 438 7c 6a d7 cb c8 23 78 30 e7 73 76 63 4b 37 31 62 439 2e af 30 d9 2e 22 a3 88 6f f1 09 27 9d 98 30 da 440 c7 27 af b9 4a 83 ee 6d 83 60 cb df a2 cc 06 40 442 scrypt (P="pleaseletmein", S="SodiumChloride", 443 r=16384, N=8, p=1, dkLen=64) = 444 70 23 bd cb 3a fd 73 48 46 1c 06 cd 81 fd 38 eb 445 fd a8 fb ba 90 4f 8e 3e a9 b5 43 f6 54 5d a1 f2 446 d5 43 29 55 61 3f 0f cf 62 d4 97 05 24 2a 9a f9 447 e6 1e 85 dc 0d 65 1e 40 df cf 01 7b 45 57 58 87 449 scrypt (P="pleaseletmein", S="SodiumChloride", 450 r=1048576, N=8, p=1, dkLen=64) = 451 21 01 cb 9b 6a 51 1a ae ad db be 09 cf 70 f8 81 452 ec 56 8d 57 4a 2f fd 4d ab e5 ee 98 20 ad aa 47 453 8e 56 fd 8f 4b a5 d0 9f fa 1c 6d 92 7c 40 f4 c3 454 37 30 40 49 e8 a9 52 fb cb f4 5c 6f a7 7a 41 a4 456 12. Acknowledgements 458 Text in this document was borrowed from [SCRYPT] and [RFC2898]. 460 13. IANA Considerations 462 None. 464 14. Security Considerations 466 This document specify a cryptographic algorithm. The reader must 467 follow cryptographic research to notice published attacks. ROMix has 468 been proven sequential memory-hard under the Random Oracle model for 469 the hash function. The security of scrypt relies on the assumption 470 that BlockMix with Salsa20/8 does not exhibit any "shortcuts" which 471 would allow it to be iterated more easily than a random oracle. For 472 other claims about the security properties see [SCRYPT]. 474 Passwords and other sensitive data, such as intermediate values, may 475 continue to be stored in memory, core dumps, swap areas, etc, a long 476 time after the implementation has finished processing them. This can 477 make attacks on the implementation easier. Thus, implementation 478 should consider storing sensitive data in protected memory areas. 479 How to achieve that is system dependent. 481 By nature and depending on parameters, running the scrypt algorithm 482 may require large amounts of memory. Systems should protect against 483 a denial of service attack resulting from attackers presenting 484 unreasonable large parameters. 486 15. References 488 15.1. Normative References 490 [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography 491 Specification Version 2.0", RFC 2898, September 2000. 493 [RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms 494 (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011. 496 [SALSA20CORE] 497 Bernstein, D., "The Salsa20 core", 498 WWW http://cr.yp.to/salsa20.html, March 2005. 500 15.2. Informative References 502 [ANSI.X3-4.1986] 503 American National Standards Institute, "Coded Character 504 Set - 7-bit American Standard Code for Information 505 Interchange", ANSI X3.4, 1986. 507 [SCRYPT] Percival, C., "Stronger key derivation via sequential 508 memory-hard functions", 509 BSDCan'09 http://www.tarsnap.com/scrypt/scrypt.pdf, 510 May 2009. 512 Authors' Addresses 514 Colin Percival 515 Tarsnap 517 Email: cperciva@tarsnap.com 519 Simon Josefsson 520 SJD AB 522 Email: simon@josefsson.org 523 URI: http://josefsson.org/