Internet Engineering Task Force (IETF) C. Percival
Request for Comments: 7914 Tarsnap
Category: Informational S. Josefsson
ISSN: 2070-1721 SJD AB
August 2016
The scrypt Password-Based Key Derivation Function
Abstract
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.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7914.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Percival & Josefsson Informational [Page 1]

RFC 7914 scrypt PBKDF August 2016
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 [SCRYPT] 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.
2. scrypt Parameters
The scrypt function takes several parameters. The passphrase P is
typically a human-chosen password. The salt is normally uniquely and
randomly generated [RFC4086]. 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
Percival & Josefsson Informational [Page 3]

RFC 7914 scrypt PBKDF August 201613. Test Vectors for PKCS#8
PKCS#8 [RFC5208] and Asymmetric Key Packages [RFC5958] 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.
-----BEGIN ENCRYPTED PRIVATE KEY-----
MIHiME0GCSqGSIb3DQEFDTBAMB8GCSsGAQQB2kcECzASBAVNb3VzZQIDEAAAAgEI
AgEBMB0GCWCGSAFlAwQBKgQQyYmguHMsOwzGMPoyObk/JgSBkJb47EWd5iAqJlyy
+ni5ftd6gZgOPaLQClL7mEZc2KQay0VhjZm/7MbBUNbqOAXNM6OGebXxVp6sHUAL
iBGY/Dls7B1TsWeGObE0sS1MXEpuREuloZjcsNVcNXWPlLdZtkSH6uwWzR0PyG/Z
+ZXfNodZtd/voKlvLOw5B3opGIFaLkbtLZQwMiGtl42AS89lZg==
-----END ENCRYPTED PRIVATE KEY-----
14. Security Considerations
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
[SCRYPT].
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.
Percival & Josefsson Informational [Page 14]