]> Tarsnap

cperciva@tarsnap.com

SJD AB

simon@josefsson.org http://josefsson.org/

PBKDF This document specifies the password-based key derivation function scrypt. The function derives one or more secret keys from a secret string. It is based on memory-hard functions, which offer added protection against attacks using custom hardware. The document also provides an ASN.1 schema.

Password-based key derivation functions are used in cryptography and security protocols for deriving one or more secret keys from a secret value. Over the years, several password-based key derivation functions have been used, including the original DES-based UNIX Crypt-function, FreeBSD MD5 crypt, Public-Key Cryptography Standards#5 (PKCS#5) PBKDF2 (typically used with SHA-1), GNU SHA-256/512 crypt, Windows NT LAN Manager (NTLM) hash, and the Blowfish-based bcrypt. These algorithms are all based on a cryptographic primitive combined with salting and/or iteration. The iteration count is used to slow down the computation, and the salt is used to make pre-computation costlier. All password-based key derivation functions mentioned above share the same weakness against powerful attackers. Provided that the number of iterations used is increased as computer systems get faster, this allows legitimate users to spend a constant amount of time on key derivation without losing ground to attackers' ever-increasing computing power -- as long as attackers are limited to the same software implementations as legitimate users. While parallelized hardware implementations may not change the number of operations performed compared to software implementations, this does not prevent them from dramatically changing the asymptotic cost, since in many contexts -- including the embarrassingly parallel task of performing a brute-force search for a passphrase -- dollar-seconds are the most appropriate units for measuring the cost of a computation. As semiconductor technology develops, circuits do not merely become faster; they also become smaller, allowing for a larger amount of parallelism at the same cost. Consequently, with existing key derivation algorithms, even when the iteration count is increased so that the time taken to verify a password remains constant, the cost of finding a password by using a brute-force attack implemented in hardware drops each year. The scrypt function aims to reduce the advantage that attackers can gain by using custom-designed parallel circuits for breaking password-based key derivation functions. This document does not introduce scrypt for the first time. The original scrypt paper was published as a peer-reviewed scientific paper and contains further background and discussions. The purpose of this document is to serve as a stable reference for documents making use of scrypt. The rest of this document is divided into sections that each describe parameter choices and algorithm steps needed for the final "scrypt" algorithm.

The scrypt function takes several parameters. The passphrase P is typically a human-chosen password. The salt is normally uniquely and randomly generated . The parameter r ("blockSize") specifies the block size. The CPU/Memory cost parameter N ("costParameter") must be larger than 1, a power of 2, and less than 2^(128 * r / 8). The parallelization parameter p ("parallelizationParameter") is a positive integer less than or equal to ((2^32-1) * 32) / (128 * r). The intended output length dkLen is the length in octets of the key to be derived ("keyLength"); it is a positive integer less than or equal to (2^32 - 1) * 32. Users of scrypt can tune the parameters N, r, and p according to the amount of memory and computing power available, the latency-bandwidth product of the memory subsystem, and the amount of parallelism desired. At the current time, r=8 and p=1 appears to yield good results, but as memory latency and CPU parallelism increase, it is likely that the optimum values for both r and p will increase. Note also that since the computations of SMix are independent, a large value of p can be used to increase the computational cost of scrypt without increasing the memory usage; so we can expect scrypt to remain useful even if the growth rates of CPU power and memory capacity diverge.

Salsa20/8 Core is a round-reduced variant of the Salsa20 Core. It is a hash function from 64-octet strings to 64-octet strings. Note that Salsa20/8 Core is not a cryptographic hash function since it is not collision resistant. See Section 8 of for its specification and for more information. The algorithm description, in C language, is included below as a stable reference, without endianness conversion and alignment.

> (32 - (b)))) void salsa20_word_specification(uint32 out[16],uint32 in[16]) { int i; uint32 x[16]; for (i = 0;i < 16;++i) x[i] = in[i]; for (i = 8;i > 0;i -= 2) { x[ 4] ^= R(x[ 0]+x[12], 7); x[ 8] ^= R(x[ 4]+x[ 0], 9); x[12] ^= R(x[ 8]+x[ 4],13); x[ 0] ^= R(x[12]+x[ 8],18); x[ 9] ^= R(x[ 5]+x[ 1], 7); x[13] ^= R(x[ 9]+x[ 5], 9); x[ 1] ^= R(x[13]+x[ 9],13); x[ 5] ^= R(x[ 1]+x[13],18); x[14] ^= R(x[10]+x[ 6], 7); x[ 2] ^= R(x[14]+x[10], 9); x[ 6] ^= R(x[ 2]+x[14],13); x[10] ^= R(x[ 6]+x[ 2],18); x[ 3] ^= R(x[15]+x[11], 7); x[ 7] ^= R(x[ 3]+x[15], 9); x[11] ^= R(x[ 7]+x[ 3],13); x[15] ^= R(x[11]+x[ 7],18); x[ 1] ^= R(x[ 0]+x[ 3], 7); x[ 2] ^= R(x[ 1]+x[ 0], 9); x[ 3] ^= R(x[ 2]+x[ 1],13); x[ 0] ^= R(x[ 3]+x[ 2],18); x[ 6] ^= R(x[ 5]+x[ 4], 7); x[ 7] ^= R(x[ 6]+x[ 5], 9); x[ 4] ^= R(x[ 7]+x[ 6],13); x[ 5] ^= R(x[ 4]+x[ 7],18); x[11] ^= R(x[10]+x[ 9], 7); x[ 8] ^= R(x[11]+x[10], 9); x[ 9] ^= R(x[ 8]+x[11],13); x[10] ^= R(x[ 9]+x[ 8],18); x[12] ^= R(x[15]+x[14], 7); x[13] ^= R(x[12]+x[15], 9); x[14] ^= R(x[13]+x[12],13); x[15] ^= R(x[14]+x[13],18); } for (i = 0;i < 16;++i) out[i] = x[i] + in[i]; } ]]>

The scryptBlockMix algorithm is the same as the BlockMix algorithm described in but with Salsa20/8 Core used as the hash function H. Below, Salsa(T) corresponds to the Salsa20/8 Core function applied to the octet vector T.

The scryptROMix algorithm is the same as the ROMix algorithm described in but with scryptBlockMix used as the hash function H and the Integerify function explained inline.

The PBKDF2-HMAC-SHA-256 function used below denotes the PBKDF2 algorithm used with HMAC-SHA-256 as the Pseudorandom Function (PRF). The HMAC-SHA-256 function generates 32-octet outputs.

This section defines ASN.1 syntax for the scrypt key derivation function (KDF). This is intended to operate on the same abstraction level as PKCS#5's PBKDF2. The OID id-scrypt below can be used where id-PBKDF2 is used, with scrypt-params corresponding to PBKDF2-params. The intended application of these definitions includes PKCS #8 and other syntax for key management. The object identifier id-scrypt identifies the scrypt key derivation function.

The parameters field associated with this OID in an AlgorithmIdentifier shall have type scrypt-params:

The fields of type scrypt-params have the following meanings: - salt specifies the salt value. It shall be an octet string. - costParameter specifies the CPU/Memory cost parameter N. - blockSize specifies the block size parameter r. - parallelizationParameter specifies the parallelization parameter. - keyLength, an optional field, is the length in octets of the derived key. The maximum key length allowed depends on the implementation; it is expected that implementation profiles may further constrain the bounds. This field only provides convenience; the key length is not cryptographically protected. To be usable in PKCS#8 and Asymmetric Key Packages, the following extension of the PBES2-KDFs type is needed:

For reference purposes, the ASN.1 syntax is presented as an ASN.1 module here.

Below is a sequence of octets that illustrate input and output values for the Salsa20/8 Core. The octets are hex encoded and whitespace is inserted for readability. The value corresponds to the first input and output pair generated by the first scrypt test vector below.

Below is a sequence of octets that illustrate input and output values for scryptBlockMix. The test vector uses an r value of 1. The octets are hex encoded and whitespace is inserted for readability. The value corresponds to the first input and output pair generated by the first scrypt test vector below.

Below is a sequence of octets that illustrate input and output values for scryptROMix. The test vector uses an r value of 1 and an N value of 16. The octets are hex encoded and whitespace is inserted for readability. The value corresponds to the first input and output pair generated by the first scrypt test vector below.

Below is a sequence of octets that illustrate input and output values for PBKDF2-HMAC-SHA-256. The octets are hex encoded and whitespace is inserted for readability. The test vectors below can be used to verify the PBKDF2-HMAC-SHA-256 function. The password and salt strings are passed as sequences of ASCII octets.

For reference purposes, we provide the following test vectors for scrypt, where the password and salt strings are passed as sequences of ASCII octets. The parameters to the scrypt function below are, in order, the password P (octet string), the salt S (octet string), the CPU/Memory cost parameter N, the block size parameter r, the parallelization parameter p, and the output size dkLen. The output is hex encoded and whitespace is inserted for readability.

PKCS#8 and Asymmetric Key Packages encode encrypted private-keys. Using PBES2 with scrypt as the KDF, the following illustrates an example of a PKCS#8-encoded private-key. The password is "Rabbit" (without the quotes) with N=1048576, r=8, and p=1. The salt is "Mouse" and the encryption algorithm used is aes256-CBC. The derived key is: E2 77 EA 2C AC B2 3E DA-FC 03 9D 22 9B 79 DC 13 EC ED B6 01 D9 9B 18 2A-9F ED BA 1E 2B FB 4F 58.

This document specifies a cryptographic algorithm, and there is always a risk that someone will find a weakness in it. By following the cryptographic research area, you may learn of publications relevant to scrypt. ROMix has been proven sequential memory-hard under the random oracle model for the hash function. The security of scrypt relies on the assumption that BlockMix with Salsa20/8 Core does not exhibit any "shortcuts" that would allow it to be iterated more easily than a random oracle. For other claims about the security properties, see . Passwords and other sensitive data, such as intermediate values, may continue to be stored in memory, core dumps, swap areas, etc., for a long time after the implementation has processed them. This makes attacks on the implementation easier. Thus, implementation should consider storing sensitive data in protected memory areas. How to achieve this is system dependent. By nature and depending on parameters, running the scrypt algorithm may require large amounts of memory. Systems should protect against a denial-of-service attack resulting from attackers presenting unreasonably large parameters. Poor parameter choices can be harmful for security; for example, if you tune the parameters so that memory use is reduced to small amounts that will affect the properties of the algorithm.

&RFC2898; &RFC6234; &RFC0020; &RFC5208; &RFC5958; &RFC4086; Microsoft

Text in this document was borrowed from and . The PKCS#8 test vector was provided by Stephen N. Henson. Feedback on this document was received from Dmitry Chestnykh, Alexander Klink, Rob Kendrick, Royce Williams, Ted Rolle, Jr., Eitan Adler, Stephen Farrel, Nikos Mavrogiannopoulos, and Paul Kyzivat.