idnits 2.17.1 draft-josefsson-scrypt-kdf-03.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 252: '... keyLength INTEGER (1..MAX) OPTIONAL }...' RFC 2119 keyword, line 294: '... 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 13, 2015) is 3271 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 330 -- Looks like a reference, but probably isn't: '2' on line 154 -- Looks like a reference, but probably isn't: '1' on line 335 -- Looks like a reference, but probably isn't: '3' on line 155 ** Obsolete normative reference: RFC 2898 (Obsoleted by RFC 8018) -- Obsolete informational reference (is this intentional?): RFC 5208 (Obsoleted by RFC 5958) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 6 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 14, 2015 SJD AB 6 May 13, 2015 8 The scrypt Password-Based Key Derivation Function 9 draft-josefsson-scrypt-kdf-03 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 14, 2015. 36 Copyright Notice 38 Copyright (c) 2015 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. The Salsa20/8 Core Function . . . . . . . . . . . . . . . . . 3 55 3. The scryptBlockMix Algorithm . . . . . . . . . . . . . . . . 3 56 4. The scryptROMix Algorithm . . . . . . . . . . . . . . . . . . 4 57 5. The scrypt Algorithm . . . . . . . . . . . . . . . . . . . . 5 58 6. ASN.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . 6 59 6.1. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . 7 60 7. Test Vectors for Salsa20/8 Core . . . . . . . . . . . . . . . 8 61 8. Test Vectors for scryptBlockMix . . . . . . . . . . . . . . . 8 62 9. Test Vectors for scryptROMix . . . . . . . . . . . . . . . . 9 63 10. Test Vectors for PBKDF2 with HMAC-SHA-256 . . . . . . . . . . 10 64 11. Test Vectors for scrypt . . . . . . . . . . . . . . . . . . . 10 65 12. Test Vectors for PKCS#8 . . . . . . . . . . . . . . . . . . . 11 66 13. Copying Conditions . . . . . . . . . . . . . . . . . . . . . 12 67 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 68 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 69 16. Security Considerations . . . . . . . . . . . . . . . . . . . 12 70 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 71 17.1. Normative References . . . . . . . . . . . . . . . . . . 13 72 17.2. Informative References . . . . . . . . . . . . . . . . . 13 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 75 1. Introduction 77 Password-based key derivation functions are used in cryptography for 78 deriving one or more secret keys from a secret value. Over the 79 years, several password-based key derivation functions have been 80 used, including the original DES-based UNIX Crypt-function, FreeBSD 81 MD5 crypt, PKCS#5 PBKDF2 [RFC2898] (typically used with SHA-1), GNU 82 SHA-256/512 crypt, Windows NT LAN Manager (NTLM) hash, and the 83 Blowfish-based bcrypt. These algorithms are based on similar 84 techniques that employ a cryptographic primitive, salting and/or 85 iteration. The iteration count is used to slow down the computation. 87 Providing that the number of iterations used is increased as computer 88 systems get faster, this allows legitimate users to spend a constant 89 amount of time on key derivation without losing ground to an 90 attackers' ever-increasing computing power - as long as attackers are 91 limited to the same software implementations as legitimate users. 92 However, as Bernstein pointed out in the context of integer 93 factorization, while parallelized hardware implementations may not 94 change the number of operations performed compared to software 95 implementations, this does not prevent them from dramatically 96 changing the asymptotic cost, since in many contexts - including the 97 embarrassingly parallel task of performing a brute-force search for a 98 passphrase - dollar-seconds are the most appropriate units for 99 measuring the cost of a computation. As semiconductor technology 100 develops, circuits do not merely become faster; they also become 101 smaller, allowing for a larger amount of parallelism at the same 102 cost. Consequently, existing key derivation algorithms, even when 103 the iteration count is increased so that the time taken to verify a 104 password remains constant, the cost of finding a password by using a 105 brute force attack implemented in hardware drops each year. 107 The scrypt function aims to reduce the advantage which attackers can 108 gain by using custom-designed parallel circuits for breaking 109 password-based key derivation functions. 111 For further background, see the original scrypt paper [SCRYPT]. 113 The rest of this document is divided into sections that each describe 114 algorithms needed for the final "scrypt" algorithm. 116 2. The Salsa20/8 Core Function 118 Salsa20/8 Core is a round-reduced variant of the Salsa20 Core. It is 119 a hash function from 64-octet strings to 64-octet strings. Note that 120 Salsa20/8 Core is not a cryptographic hash function since it is not 121 collision-resistant. See section 8 of [SALSA20SPEC] for its 122 specification, and [SALSA20CORE] for more information. 124 3. The scryptBlockMix Algorithm 126 The scryptBlockMix algorithm is the same as the BlockMix algorithm 127 described in [SCRYPT] but with Salsa20/8 Core used as the hash 128 function H. Below, Salsa(T) corresponds to the Salsa20/8 Core 129 function applied to the octet vector T. 131 Algorithm scryptBlockMix 133 Parameters: 134 r Block size parameter. 136 Input: 137 B[0], ..., B[2 * r - 1] 138 Input vector of 2 * r 64-octet blocks. 140 Output: 141 B'[0], ..., B'[2 * r - 1] 142 Output vector of 2 * r 64-octet blocks. 144 Steps: 146 1. X = B[2 * r - 1] 148 2. for i = 0 to 2 * r - 1 do 149 T = X xor B[i] 150 X = Salsa (T) 151 Y[i] = X 152 end for 154 3. B' = (Y[0], Y[2], ..., Y[2 * r - 2], 155 Y[1], Y[3], ..., Y[2 * r - 1]) 157 4. The scryptROMix Algorithm 159 The scryptROMix algorithm is the same as the ROMix algorithm 160 described in [SCRYPT] but with scryptBlockMix used as the hash 161 function H and the Integerify function explained inline. 163 Algorithm scryptROMix 165 Input: 166 r Block size parameter. 167 B Input octet vector of length 128 * r octets. 168 N CPU/Memory cost parameter, must be larger than 1, 169 a power of 2 and less than 2^(128 * r / 8). 171 Output: 172 B' Output octet vector of length 128 * r octets. 174 Steps: 176 1. X = B 178 2. for i = 0 to N - 1 do 179 V[i] = X 180 X = scryptBlockMix (X) 181 end for 183 3. for i = 0 to N - 1 do 184 j = Integerify (X) mod N 185 where Integerify (B[0] ... B[2 * r - 1]) is defined 186 as the result of interpreting B[2 * r - 1] as a 187 little-endian integer. 188 T = X xor V[j] 189 X = scryptBlockMix (T) 190 end for 192 4. B' = X 194 5. The scrypt Algorithm 196 The PBKDF2-HMAC-SHA-256 function used below denote the PBKDF2 197 algorithm [RFC2898] used with HMAC-SHA-256 [RFC6234] as the PRF. The 198 HMAC-SHA-256 function generates 32 octet outputs. 200 Algorithm scrypt 202 Input: 203 P Passphrase, an octet string. 204 S Salt, an octet string. 205 N CPU/Memory cost parameter, must be larger than 1, 206 a power of 2 and less than 2^(128 * r / 8). 207 r Block size parameter. 208 p Parallelization parameter, a positive integer 209 less than or equal to ((2^32-1) * hLen) / MFLen 210 where hLen is 32 and MFlen is 128 * r. 211 dkLen Intended output length in octets of the derived 212 key; a positive integer less than or equal to 213 (2^32 - 1) * hLen where hLen is 32. 215 Output: 216 DK Derived key, of length dkLen octets. 218 Steps: 220 1. B[0] || B[1] || ... || B[p - 1] = 221 PBKDF2-HMAC-SHA256 (P, S, 1, p * 128 * r) 223 2. for i = 0 to p - 1 do 224 B[i] = scryptROMix (r, B[i], N) 225 end for 227 3. DK = PBKDF2-HMAC-SHA256 (P, B[0] || B[1] || ... || B[p - 1], 228 1, dkLen) 230 6. ASN.1 Syntax 232 This section defines ASN.1 syntax for the scrypt key derivation 233 function. This is intended to operate on the same abstraction level 234 as PKCS#5's PBKDF2. The OID id-scrypt below can be used where id- 235 PBKDF2 is used, with scrypt-params corresponding to PBKDF2-params. 236 The intended application of these definitions includes PKCS #8 and 237 other syntax for key management. 239 The object identifier id-scrypt identifies the scrypt key derivation 240 function. 242 id-scrypt OBJECT IDENTIFIER ::= {1 3 6 1 4 1 11591 4 11} 244 The parameters field associated with this OID in an 245 AlgorithmIdentifier shall have type scrypt-params: 247 scrypt-params ::= SEQUENCE { 248 salt OCTET STRING, 249 costParameter INTEGER (1..MAX), 250 blockSize INTEGER (1..MAX), 251 parallelizationParameter INTEGER (1..MAX), 252 keyLength INTEGER (1..MAX) OPTIONAL } 254 The fields of type scrypt-params have the following meanings: 256 - salt specifies the salt value. It shall be an octet string. 258 - costParameter specifies the CPU/Memory cost parameter N. 260 - blockSize specifies the block size parameter r. 262 - parallelizationParameter specifies the parallelization parameter. 264 - keyLength, an optional field, is the length in octets of the 265 derived key. The maximum key length allowed depends on the 266 implementation; it is expected that implementation profiles may 267 further constrain the bounds. This field only provides convenience; 268 the key length is not cryptographically protected. 270 To be usable in PKCS#8 [RFC5208] and Asymmetric Key Packages 271 [RFC5958] the following extension of the PBES2-KDFs type is needed. 273 PBES2-KDFs ALGORITHM-IDENTIFIER ::= 274 { {scrypt-params IDENTIFIED BY id-scrypt}, ... } 276 6.1. ASN.1 Module 278 For reference purposes, the ASN.1 syntax is presented as an ASN.1 279 module here. 281 -- scrypt ASN.1 Module 283 scrypt-0 {1 3 6 1 4 1 11591 4 10} 285 DEFINITIONS ::= BEGIN 287 id-scrypt OBJECT IDENTIFIER ::= {1 3 6 1 4 1 11591 4 11} 289 scrypt-params ::= SEQUENCE { 290 salt OCTET STRING, 291 costParameter INTEGER (1..MAX), 292 blockSize INTEGER (1..MAX), 293 parallelizationParameter INTEGER (1..MAX), 294 keyLength INTEGER (1..MAX) OPTIONAL 295 } 297 PBES2-KDFs ALGORITHM-IDENTIFIER ::= 298 { {scrypt-params IDENTIFIED BY id-scrypt}, ... } 300 END 302 7. Test Vectors for Salsa20/8 Core 304 Below is a sequence of octets to illustrate input and output values 305 for the Salsa20/8 Core. The octets are hex encoded and whitespace is 306 inserted for readability. The value corresponds to the first input 307 and output pair generated by the first scrypt test vector below. 309 INPUT: 310 7e 87 9a 21 4f 3e c9 86 7c a9 40 e6 41 71 8f 26 311 ba ee 55 5b 8c 61 c1 b5 0d f8 46 11 6d cd 3b 1d 312 ee 24 f3 19 df 9b 3d 85 14 12 1e 4b 5a c5 aa 32 313 76 02 1d 29 09 c7 48 29 ed eb c6 8d b8 b8 c2 5e 315 OUTPUT: 316 a4 1f 85 9c 66 08 cc 99 3b 81 ca cb 02 0c ef 05 317 04 4b 21 81 a2 fd 33 7d fd 7b 1c 63 96 68 2f 29 318 b4 39 31 68 e3 c9 e6 bc fe 6b c5 b7 a0 6d 96 ba 319 e4 24 cc 10 2c 91 74 5c 24 ad 67 3d c7 61 8f 81 321 8. Test Vectors for scryptBlockMix 323 Below is a sequence of octets to illustrate input and output values 324 for scryptBlockMix. The test vector uses an r value of 1. The 325 octets are hex encoded and whitespace is inserted for readability. 326 The value corresponds to the first input and output pair generated by 327 the first scrypt test vector below. 329 INPUT 330 B[0] = f7 ce 0b 65 3d 2d 72 a4 10 8c f5 ab e9 12 ff dd 331 77 76 16 db bb 27 a7 0e 82 04 f3 ae 2d 0f 6f ad 332 89 f6 8f 48 11 d1 e8 7b cc 3b d7 40 0a 9f fd 29 333 09 4f 01 84 63 95 74 f3 9a e5 a1 31 52 17 bc d7 335 B[1] = 89 49 91 44 72 13 bb 22 6c 25 b5 4d a8 63 70 fb 336 cd 98 43 80 37 46 66 bb 8f fc b5 bf 40 c2 54 b0 337 67 d2 7c 51 ce 4a d5 fe d8 29 c9 0b 50 5a 57 1b 338 7f 4d 1c ad 6a 52 3c da 77 0e 67 bc ea af 7e 89 340 OUTPUT 341 B'[0] = a4 1f 85 9c 66 08 cc 99 3b 81 ca cb 02 0c ef 05 342 04 4b 21 81 a2 fd 33 7d fd 7b 1c 63 96 68 2f 29 343 b4 39 31 68 e3 c9 e6 bc fe 6b c5 b7 a0 6d 96 ba 344 e4 24 cc 10 2c 91 74 5c 24 ad 67 3d c7 61 8f 81 346 B'[1] = 20 ed c9 75 32 38 81 a8 05 40 f6 4c 16 2d cd 3c 347 21 07 7c fe 5f 8d 5f e2 b1 a4 16 8f 95 36 78 b7 348 7d 3b 3d 80 3b 60 e4 ab 92 09 96 e5 9b 4d 53 b6 349 5d 2a 22 58 77 d5 ed f5 84 2c b9 f1 4e ef e4 25 351 9. Test Vectors for scryptROMix 353 Below is a sequence of octets to illustrate input and output values 354 for scryptROMix. The test vector uses an r value of 1 and an N value 355 of 16. The octets are hex encoded and whitespace is inserted for 356 readability. The value corresponds to the first input and output 357 pair generated by the first scrypt test vector below. 359 INPUT: 360 B = f7 ce 0b 65 3d 2d 72 a4 10 8c f5 ab e9 12 ff dd 361 77 76 16 db bb 27 a7 0e 82 04 f3 ae 2d 0f 6f ad 362 89 f6 8f 48 11 d1 e8 7b cc 3b d7 40 0a 9f fd 29 363 09 4f 01 84 63 95 74 f3 9a e5 a1 31 52 17 bc d7 364 89 49 91 44 72 13 bb 22 6c 25 b5 4d a8 63 70 fb 365 cd 98 43 80 37 46 66 bb 8f fc b5 bf 40 c2 54 b0 366 67 d2 7c 51 ce 4a d5 fe d8 29 c9 0b 50 5a 57 1b 367 7f 4d 1c ad 6a 52 3c da 77 0e 67 bc ea af 7e 89 369 OUTPUT: 370 B = 79 cc c1 93 62 9d eb ca 04 7f 0b 70 60 4b f6 b6 371 2c e3 dd 4a 96 26 e3 55 fa fc 61 98 e6 ea 2b 46 372 d5 84 13 67 3b 99 b0 29 d6 65 c3 57 60 1f b4 26 373 a0 b2 f4 bb a2 00 ee 9f 0a 43 d1 9b 57 1a 9c 71 374 ef 11 42 e6 5d 5a 26 6f dd ca 83 2c e5 9f aa 7c 375 ac 0b 9c f1 be 2b ff ca 30 0d 01 ee 38 76 19 c4 376 ae 12 fd 44 38 f2 03 a0 e4 e1 c4 7e c3 14 86 1f 377 4e 90 87 cb 33 39 6a 68 73 e8 f9 d2 53 9a 4b 8e 379 10. Test Vectors for PBKDF2 with HMAC-SHA-256 381 Below is a sequence of octets illustring input and output values for 382 PBKDF2-HMAC-SHA-256. The octets are hex encoded and whitespace is 383 inserted for readability. The test vectors below can be used to 384 verify the PBKDF2-HMAC-SHA-256 [RFC2898] function. The password and 385 salt strings are passed as sequences of ASCII [RFC0020] octets. 387 PBKDF2-HMAC-SHA-256 (P="passwd", S="salt", 388 c=1, dkLen=64) = 389 55 ac 04 6e 56 e3 08 9f ec 16 91 c2 25 44 b6 05 390 f9 41 85 21 6d de 04 65 e6 8b 9d 57 c2 0d ac bc 391 49 ca 9c cc f1 79 b6 45 99 16 64 b3 9d 77 ef 31 392 7c 71 b8 45 b1 e3 0b d5 09 11 20 41 d3 a1 97 83 394 PBKDF2-HMAC-SHA-256 (P="Password", S="NaCl", 395 c=80000, dkLen=64) = 396 4d dc d8 f6 0b 98 be 21 83 0c ee 5e f2 27 01 f9 397 64 1a 44 18 d0 4c 04 14 ae ff 08 87 6b 34 ab 56 398 a1 d4 25 a1 22 58 33 54 9a db 84 1b 51 c9 b3 17 399 6a 27 2b de bb a1 d0 78 47 8f 62 b3 97 f3 3c 8d 401 11. Test Vectors for scrypt 403 For reference purposes, we provide the following test vectors for 404 scrypt, where the password and salt strings are passed as sequences 405 of ASCII [RFC0020] octets. 407 The parameters to the scrypt function below are, in order, the 408 password P (octet string), the salt S (octet string), the CPU/Memory 409 cost parameter N, the block size parameter r, and the parallelization 410 parameter p, and the output size dkLen. The output is hex encoded 411 and whitespace is inserted for readability. 413 scrypt (P="", S="", 414 N=16, r=1, p=1, dklen=64) = 415 77 d6 57 62 38 65 7b 20 3b 19 ca 42 c1 8a 04 97 416 f1 6b 48 44 e3 07 4a e8 df df fa 3f ed e2 14 42 417 fc d0 06 9d ed 09 48 f8 32 6a 75 3a 0f c8 1f 17 418 e8 d3 e0 fb 2e 0d 36 28 cf 35 e2 0c 38 d1 89 06 420 scrypt (P="password", S="NaCl", 421 N=1024, r=8, p=16, dkLen=64) = 422 fd ba be 1c 9d 34 72 00 78 56 e7 19 0d 01 e9 fe 423 7c 6a d7 cb c8 23 78 30 e7 73 76 63 4b 37 31 62 424 2e af 30 d9 2e 22 a3 88 6f f1 09 27 9d 98 30 da 425 c7 27 af b9 4a 83 ee 6d 83 60 cb df a2 cc 06 40 427 scrypt (P="pleaseletmein", S="SodiumChloride", 428 N=16384, r=8, p=1, dkLen=64) = 429 70 23 bd cb 3a fd 73 48 46 1c 06 cd 81 fd 38 eb 430 fd a8 fb ba 90 4f 8e 3e a9 b5 43 f6 54 5d a1 f2 431 d5 43 29 55 61 3f 0f cf 62 d4 97 05 24 2a 9a f9 432 e6 1e 85 dc 0d 65 1e 40 df cf 01 7b 45 57 58 87 434 scrypt (P="pleaseletmein", S="SodiumChloride", 435 N=1048576, r=8, p=1, dkLen=64) = 436 21 01 cb 9b 6a 51 1a ae ad db be 09 cf 70 f8 81 437 ec 56 8d 57 4a 2f fd 4d ab e5 ee 98 20 ad aa 47 438 8e 56 fd 8f 4b a5 d0 9f fa 1c 6d 92 7c 40 f4 c3 439 37 30 40 49 e8 a9 52 fb cb f4 5c 6f a7 7a 41 a4 441 12. Test Vectors for PKCS#8 443 PKCS#8 [RFC5208] and Asymmetric Key Packages [RFC5958] encode 444 encrypted private-keys. Using PBES2 with scrypt as the KDF, the 445 following illustrates an example of a PKCS#8 encoded private-key. 446 The password is "Rabbit" (without the quotes) with N=1048576, r=8 and 447 p=1. The salt is "Mouse" and the encryption algorithm used is 448 aes256-CBC. The derived key is: E2 77 EA 2C AC B2 3E DA-FC 03 9D 22 449 9B 79 DC 13 EC ED B6 01 D9 9B 18 2A-9F ED BA 1E 2B FB 4F 58. 451 -----BEGIN ENCRYPTED PRIVATE KEY----- 452 MIHiME0GCSqGSIb3DQEFDTBAMB8GCSsGAQQB2kcECzASBAVNb3VzZQIDEAAAAgEI 453 AgEBMB0GCWCGSAFlAwQBKgQQyYmguHMsOwzGMPoyObk/JgSBkJb47EWd5iAqJlyy 454 +ni5ftd6gZgOPaLQClL7mEZc2KQay0VhjZm/7MbBUNbqOAXNM6OGebXxVp6sHUAL 455 iBGY/Dls7B1TsWeGObE0sS1MXEpuREuloZjcsNVcNXWPlLdZtkSH6uwWzR0PyG/Z 456 +ZXfNodZtd/voKlvLOw5B3opGIFaLkbtLZQwMiGtl42AS89lZg== 457 -----END ENCRYPTED PRIVATE KEY----- 459 13. Copying Conditions 461 The authors agree to grant third parties the irrevocable right to 462 copy, use and distribute this entire document or any portion of it, 463 with or without modification, in any medium, without royalty, 464 provided that, unless separate permission is granted, redistributed 465 modified works do not contain misleading author, version, name of 466 work, or endorsement information. 468 14. Acknowledgements 470 Text in this document was borrowed from [SCRYPT] and [RFC2898]. The 471 PKCS#8 test vector was provided by Stephen N. Henson. 473 Feedback on this document were received from Dmitry Chestnykh, 474 Alexander Klink, Rob Kendrick, Royce Williams Ted Rolle, Jr., and 475 Eitan Adler. 477 15. IANA Considerations 479 None. 481 16. Security Considerations 483 This document specifies a cryptographic algorithm. The reader must 484 follow cryptographic research of published attacks. ROMix has been 485 proven sequential memory-hard under the Random Oracle model for the 486 hash function. The security of scrypt relies on the assumption that 487 BlockMix with Salsa20/8 Core does not exhibit any "shortcuts" which 488 would allow it to be iterated more easily than a random oracle. For 489 other claims about the security properties see [SCRYPT]. 491 Passwords and other sensitive data, such as intermediate values, may 492 continue to be stored in memory, core dumps, swap areas, etc, for a 493 long time after the implementation has processed them. This makes 494 attacks on the implementation easier. Thus, implementation should 495 consider storing sensitive data in protected memory areas. How to 496 achieve this is system dependent. 498 By nature and depending on parameters, running the scrypt algorithm 499 may require large amounts of memory. Systems should protect against 500 a denial of service attack resulting from attackers presenting 501 unreasonably large parameters. 503 17. References 505 17.1. Normative References 507 [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography 508 Specification Version 2.0", RFC 2898, September 2000. 510 [RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms 511 (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011. 513 [SALSA20SPEC] 514 Bernstein, D., "Salsa20 specification", WWW 515 http://cr.yp.to/snuffle/spec.pdf, April 2005. 517 [SALSA20CORE] 518 Bernstein, D., "The Salsa20 Core", WWW 519 http://cr.yp.to/salsa20.html, March 2005. 521 17.2. Informative References 523 [RFC0020] Cerf, V., "ASCII format for network interchange", RFC 20, 524 October 1969. 526 [RFC5208] Kaliski, B., "Public-Key Cryptography Standards (PKCS) #8: 527 Private-Key Information Syntax Specification Version 1.2", 528 RFC 5208, May 2008. 530 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, August 531 2010. 533 [SCRYPT] Percival, C., "Stronger key derivation via sequential 534 memory-hard functions", BSDCan'09 535 http://www.tarsnap.com/scrypt/scrypt.pdf, May 2009. 537 Authors' Addresses 539 Colin Percival 540 Tarsnap 542 Email: cperciva@tarsnap.com 543 Simon Josefsson 544 SJD AB 546 Email: simon@josefsson.org 547 URI: http://josefsson.org/