One document matched: draft-josefsson-scrypt-kdf-01.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2898 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2898.xml'>
<!ENTITY RFC6234 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6234.xml'>
<!ENTITY ascii PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml2/_reference.ANSI.X3-4.1986.xml'>
]>
<?rfc compact="no"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<rfc category="info" ipr="trust200902"
docName="draft-josefsson-scrypt-kdf-01">
<front>
<title abbrev="scrypt">
The scrypt Password-Based Key Derivation Function
</title>
<author initials="C." surname="Percival"
fullname="Colin Percival">
<organization>Tarsnap</organization>
<address>
<email>cperciva@tarsnap.com</email>
</address>
</author>
<author initials="S." surname="Josefsson"
fullname="Simon Josefsson">
<organization>SJD AB</organization>
<address>
<email>simon@josefsson.org</email>
<uri>http://josefsson.org/</uri>
</address>
</author>
<date month="September" year="2012"/>
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<section anchor="intro"
title="Introduction">
<t>Password-based key derivation functions are used in
cryptography 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, <xref target="RFC2898">PKCS#5
PBKDF2</xref> (typically used with SHA-1), GNU SHA-256/512
crypt, Windows NT LAN Manager (NTLM) hash, and the
Blowfish-based bcrypt. These algorithms are based on similar
techniques that employ a cryptographic primitive, salting and/or
iteration. The iteration count is used to slow down the
computation.</t>
<t>Providing 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 an attackers' ever-increasing computing power - as
long as attackers are limited to the same software
implementations as legitimate users. However, as Bernstein
pointed out in the context of integer factorization, 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, 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.</t>
<t>The scrypt function aims to reduce the advantage which
attackers can gain by using custom-designed parallel circuits
for breaking password-based key derivation functions.</t>
<t>For further background, see the original <xref
target="SCRYPT">scrypt paper</xref>.</t>
<t>The rest of this document is divided into sections that each
describe algorithms needed for the final "scrypt" algorithm.</t>
</section>
<section anchor="Salsa208core"
title="The Salsa20/8 Core Function">
<t>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 <xref
target="SALSA20CORE" /> for the specification.</t>
</section>
<section anchor="scryptBlockMix-algorithm"
title="The scryptBlockMix Algorithm">
<t>The scryptBlockMix algorithm is the same as the BlockMix
algorithm described in <xref target="SCRYPT" /> 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.</t>
<figure>
<artwork><![CDATA[
Algorithm scryptBlockMix
Parameters:
r Block size parameter.
Input:
B[0], ..., B[2 * r - 1]
Input vector of 2 * r 64-octet blocks.
Output:
B'[0], ..., B'[2 * r - 1]
Output vector of 2 * r 64-octet blocks.
Steps:
1. X = B[2 * r - 1]
2. for i = 0 to 2 * r - 1 do
T = X xor B[i]
X = Salsa (T)
Y[i] = X
end for
3. B' = (Y[0], Y[2], ..., Y[2 * r - 2],
Y[1], Y[3], ..., Y[2 * r - 1])
]]></artwork>
</figure>
</section>
<section anchor="scryptROMix-algorithm"
title="The scryptROMix Algorithm">
<t>The scryptROMix algorithm is the same as the ROMix algorithm
described in <xref target="SCRYPT" /> but with scryptBlockMix
used as the hash function H and the Integerify function
explained inline.</t>
<figure>
<artwork><![CDATA[
Algorithm scryptROMix
Input:
r Block size parameter.
B Input octet vector of length 128 * r octets.
N CPU/Memory cost parameter, must be larger than 1,
a power of 2 and less than 2^(128 * r / 8).
Output:
B' Output octet vector of length 128 * r octets.
Steps:
1. X = B
2. for i = 0 to N - 1 do
V[i] = X
X = scryptBlockMix (X)
end for
3. for i = 0 to N - 1 do
j = Integerify (X) mod N
where Integerify (B[0] ... B[2 * r - 1]) is defined
as the result of interpreting B[2 * r - 1] as a
little-endian integer.
T = X xor V[j]
X = scryptBlockMix (T)
end for
4. B' = X
]]></artwork>
</figure>
</section>
<section anchor="scrypt-algorithm"
title="The scrypt Algorithm">
<t>The PBKDF2-HMAC-SHA-256 function used below denote the <xref
target="RFC2898">PBKDF2 algorithm</xref> used with <xref
target="RFC6234">HMAC-SHA-256</xref> as the PRF. The
HMAC-SHA-256 function generates 32 octet outputs.</t>
<figure>
<artwork><![CDATA[
Algorithm scrypt
Input:
P Passphrase, an octet string.
S Salt, an octet string.
N CPU/Memory cost parameter, must be larger than 1,
a power of 2 and less than 2^(128 * r / 8).
r Block size parameter.
p Parallelization parameter, a positive integer
less than or equal to ((2^32-1) * hLen) / MFLen
where hLen is 32 and MFlen is 128 * r.
dkLen Intended output length in octets of the derived
key; a positive integer less than or equal to
(2^32 - 1) * hLen where hLen is 32.
Output:
DK Derived key, of length dkLen octets.
Steps:
1. B[0] || B[1] || ... || B[p - 1] =
PBKDF2-HMAC-SHA256 (P, S, 1, p * 128 * r)
2. for i = 0 to p - 1 do
B[i] = scryptROMix (r, B[i], N)
end for
3. DK = PBKDF2-HMAC-SHA256 (P, B[0] || B[1] || ... || B[p - 1],
1, dkLen)
]]></artwork>
</figure>
</section>
<section anchor="asn1"
title="ASN.1 Syntax">
<t>This section defines ASN.1 syntax for the scrypt key
derivation function. The intended application of these
definitions includes PKCS #8 and other syntax for key
management. (Various aspects of ASN.1 are specified in several
ISO/IEC standards.)</t>
<t>The object identifier id-scrypt identifies the scrypt key
derivation function.</t>
<figure>
<artwork><![CDATA[
id-scrypt OBJECT IDENTIFIER ::= {1 3 6 1 4 1 11591 4 11}
]]></artwork>
</figure>
<t>The parameters field associated with this OID in an
AlgorithmIdentifier shall have type scrypt-params:</t>
<figure>
<artwork><![CDATA[
scrypt-params ::= SEQUENCE {
salt OCTET STRING,
costParameter INTEGER (1..MAX),
blockSize INTEGER (1..MAX),
parallelizationParameter INTEGER (1..MAX),
keyLength INTEGER (1..MAX) OPTIONAL }
]]></artwork>
</figure>
<t>The fields of type scrypt-params have the following
meanings:</t>
<t>- salt specifies the salt value. It shall be an octet
string.</t>
<t>- costParameter specifies the CPU/Memory cost parameter N.</t>
<t>- blockSize specifies the block size parameter r.</t>
<t>- parallelizationParameter specifies the parallelization
parameter.</t>
<t>- 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.</t>
<section title="ASN.1 Module">
<t>For reference purposes, the ASN.1 syntax is presented as an
ASN.1 module here.</t>
<figure>
<artwork><![CDATA[
-- scrypt ASN.1 Module
scrypt-0 {1 3 6 1 4 1 11591 4 10}
DEFINITIONS ::= BEGIN
id-scrypt OBJECT IDENTIFIER ::= {1 3 6 1 4 1 11591 4 11}
scrypt-params ::= SEQUENCE {
salt OCTET STRING,
costParameter INTEGER (1..MAX),
blockSize INTEGER (1..MAX),
parallelizationParameter INTEGER (1..MAX),
keyLength INTEGER (1..MAX) OPTIONAL
}
END
]]></artwork>
</figure>
</section>
</section>
<section anchor="salsa208core-test-vectors"
title="Test Vectors for Salsa20/8 Core">
<t>Below is a sequence of octets to 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.</t>
<figure>
<artwork><![CDATA[
INPUT:
7e 87 9a 21 4f 3e c9 86 7c a9 40 e6 41 71 8f 26
ba ee 55 5b 8c 61 c1 b5 0d f8 46 11 6d cd 3b 1d
ee 24 f3 19 df 9b 3d 85 14 12 1e 4b 5a c5 aa 32
76 02 1d 29 09 c7 48 29 ed eb c6 8d b8 b8 c2 5e
OUTPUT:
a4 1f 85 9c 66 08 cc 99 3b 81 ca cb 02 0c ef 05
04 4b 21 81 a2 fd 33 7d fd 7b 1c 63 96 68 2f 29
b4 39 31 68 e3 c9 e6 bc fe 6b c5 b7 a0 6d 96 ba
e4 24 cc 10 2c 91 74 5c 24 ad 67 3d c7 61 8f 81
]]></artwork>
</figure>
</section>
<section anchor="scryptBlockMix-test-vectors"
title="Test Vectors for scryptBlockMix">
<t>Below is a sequence of octets to 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.</t>
<figure>
<artwork><![CDATA[
INPUT
B[0] = f7 ce 0b 65 3d 2d 72 a4 10 8c f5 ab e9 12 ff dd
77 76 16 db bb 27 a7 0e 82 04 f3 ae 2d 0f 6f ad
89 f6 8f 48 11 d1 e8 7b cc 3b d7 40 0a 9f fd 29
09 4f 01 84 63 95 74 f3 9a e5 a1 31 52 17 bc d7
B[1] = 89 49 91 44 72 13 bb 22 6c 25 b5 4d a8 63 70 fb
cd 98 43 80 37 46 66 bb 8f fc b5 bf 40 c2 54 b0
67 d2 7c 51 ce 4a d5 fe d8 29 c9 0b 50 5a 57 1b
7f 4d 1c ad 6a 52 3c da 77 0e 67 bc ea af 7e 89
OUTPUT
B'[0] = a4 1f 85 9c 66 08 cc 99 3b 81 ca cb 02 0c ef 05
04 4b 21 81 a2 fd 33 7d fd 7b 1c 63 96 68 2f 29
b4 39 31 68 e3 c9 e6 bc fe 6b c5 b7 a0 6d 96 ba
e4 24 cc 10 2c 91 74 5c 24 ad 67 3d c7 61 8f 81
B'[1] = 20 ed c9 75 32 38 81 a8 05 40 f6 4c 16 2d cd 3c
21 07 7c fe 5f 8d 5f e2 b1 a4 16 8f 95 36 78 b7
7d 3b 3d 80 3b 60 e4 ab 92 09 96 e5 9b 4d 53 b6
5d 2a 22 58 77 d5 ed f5 84 2c b9 f1 4e ef e4 25
]]></artwork>
</figure>
</section>
<section anchor="scryptROMix-test-vectors"
title="Test Vectors for scryptROMix">
<t>Below is a sequence of octets to 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.</t>
<figure>
<artwork><![CDATA[
INPUT:
B = f7 ce 0b 65 3d 2d 72 a4 10 8c f5 ab e9 12 ff dd
77 76 16 db bb 27 a7 0e 82 04 f3 ae 2d 0f 6f ad
89 f6 8f 48 11 d1 e8 7b cc 3b d7 40 0a 9f fd 29
09 4f 01 84 63 95 74 f3 9a e5 a1 31 52 17 bc d7
89 49 91 44 72 13 bb 22 6c 25 b5 4d a8 63 70 fb
cd 98 43 80 37 46 66 bb 8f fc b5 bf 40 c2 54 b0
67 d2 7c 51 ce 4a d5 fe d8 29 c9 0b 50 5a 57 1b
7f 4d 1c ad 6a 52 3c da 77 0e 67 bc ea af 7e 89
OUTPUT:
B = 79 cc c1 93 62 9d eb ca 04 7f 0b 70 60 4b f6 b6
2c e3 dd 4a 96 26 e3 55 fa fc 61 98 e6 ea 2b 46
d5 84 13 67 3b 99 b0 29 d6 65 c3 57 60 1f b4 26
a0 b2 f4 bb a2 00 ee 9f 0a 43 d1 9b 57 1a 9c 71
ef 11 42 e6 5d 5a 26 6f dd ca 83 2c e5 9f aa 7c
ac 0b 9c f1 be 2b ff ca 30 0d 01 ee 38 76 19 c4
ae 12 fd 44 38 f2 03 a0 e4 e1 c4 7e c3 14 86 1f
4e 90 87 cb 33 39 6a 68 73 e8 f9 d2 53 9a 4b 8e
]]></artwork>
</figure>
</section>
<section anchor="pbkdf2-hmac-sha256-test-vectors"
title="Test Vectors for PBKDF2 with HMAC-SHA-256">
<t>Below is a sequence of octets illustring 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 <xref
target="RFC2898">PBKDF2-HMAC-SHA-256</xref> function. The
password and salt strings are passed as sequences of <xref
target="ANSI.X3-4.1986">ASCII</xref> octets.</t>
<figure>
<artwork><![CDATA[
PBKDF2-HMAC-SHA-256 (P="passwd", S="salt",
c=1, dkLen=64) =
55 ac 04 6e 56 e3 08 9f ec 16 91 c2 25 44 b6 05
f9 41 85 21 6d de 04 65 e6 8b 9d 57 c2 0d ac bc
49 ca 9c cc f1 79 b6 45 99 16 64 b3 9d 77 ef 31
7c 71 b8 45 b1 e3 0b d5 09 11 20 41 d3 a1 97 83
]]></artwork>
</figure>
<figure>
<artwork><![CDATA[
PBKDF2-HMAC-SHA-256 (P="Password", S="NaCl",
c=80000, dkLen=64) =
4d dc d8 f6 0b 98 be 21 83 0c ee 5e f2 27 01 f9
64 1a 44 18 d0 4c 04 14 ae ff 08 87 6b 34 ab 56
a1 d4 25 a1 22 58 33 54 9a db 84 1b 51 c9 b3 17
6a 27 2b de bb a1 d0 78 47 8f 62 b3 97 f3 3c 8d
]]></artwork>
</figure>
</section>
<section anchor="scrypt-test-vectors"
title="Test Vectors for scrypt">
<t>For reference purposes, we provide the following test vectors
for scrypt, where the password and salt strings are passed as
sequences of <xref target="ANSI.X3-4.1986">ASCII</xref>
octets.</t>
<t>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, and the
parallelization parameter p, and the output size dkLen. The
output is hex encoded and whitespace is inserted for
readability.</t>
<figure>
<artwork><![CDATA[
scrypt (P="", S="",
N=16, r=1, p=1, dklen=64) =
77 d6 57 62 38 65 7b 20 3b 19 ca 42 c1 8a 04 97
f1 6b 48 44 e3 07 4a e8 df df fa 3f ed e2 14 42
fc d0 06 9d ed 09 48 f8 32 6a 75 3a 0f c8 1f 17
e8 d3 e0 fb 2e 0d 36 28 cf 35 e2 0c 38 d1 89 06
]]></artwork>
</figure>
<figure>
<artwork><![CDATA[
scrypt (P="password", S="NaCl",
N=1024, r=8, p=16, dkLen=64) =
fd ba be 1c 9d 34 72 00 78 56 e7 19 0d 01 e9 fe
7c 6a d7 cb c8 23 78 30 e7 73 76 63 4b 37 31 62
2e af 30 d9 2e 22 a3 88 6f f1 09 27 9d 98 30 da
c7 27 af b9 4a 83 ee 6d 83 60 cb df a2 cc 06 40
]]></artwork>
</figure>
<figure>
<artwork><![CDATA[
scrypt (P="pleaseletmein", S="SodiumChloride",
N=16384, r=8, p=1, dkLen=64) =
70 23 bd cb 3a fd 73 48 46 1c 06 cd 81 fd 38 eb
fd a8 fb ba 90 4f 8e 3e a9 b5 43 f6 54 5d a1 f2
d5 43 29 55 61 3f 0f cf 62 d4 97 05 24 2a 9a f9
e6 1e 85 dc 0d 65 1e 40 df cf 01 7b 45 57 58 87
]]></artwork>
</figure>
<figure>
<artwork><![CDATA[
scrypt (P="pleaseletmein", S="SodiumChloride",
N=1048576, r=8, p=1, dkLen=64) =
21 01 cb 9b 6a 51 1a ae ad db be 09 cf 70 f8 81
ec 56 8d 57 4a 2f fd 4d ab e5 ee 98 20 ad aa 47
8e 56 fd 8f 4b a5 d0 9f fa 1c 6d 92 7c 40 f4 c3
37 30 40 49 e8 a9 52 fb cb f4 5c 6f a7 7a 41 a4
]]></artwork>
</figure>
</section>
<section anchor="copying-conditions"
title="Copying Conditions">
<t>The authors agree to grant third parties the irrevocable
right to copy, use and distribute this entire document or any
portion of it, with or without modification, in any medium,
without royalty, provided that, unless separate permission is
granted, redistributed modified works do not contain misleading
author, version, name of work, or endorsement information.</t>
</section>
<section anchor="ack"
title="Acknowledgements">
<t>Text in this document was borrowed from <xref
target="SCRYPT"/> and <xref target="RFC2898"/>.</t>
<t>Feedback on this document were received from Dmitry
Chestnykh, Alexander Klink, Rob Kendrick, Royce Williams Ted
Rolle, Jr., and Eitan Adler.</t>
</section>
<section anchor="iana"
title="IANA Considerations">
<t>None.</t>
</section>
<section anchor="security"
title="Security Considerations">
<t>This document specifies a cryptographic algorithm. The
reader must follow cryptographic research of published attacks.
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" which would allow it to be iterated
more easily than a random oracle. For other claims about the
security properties see <xref target="SCRYPT"/>.</t>
<t>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.</t>
<t>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.</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2898;
&RFC6234;
<reference anchor="SALSA20CORE">
<front>
<title>The Salsa20 Core</title>
<author initials="D.J." surname="Bernstein"
fullname="D.J. Bernstein"/>
<date month="March" year="2005" />
</front>
<seriesInfo name="WWW" value="http://cr.yp.to/salsa20.html" />
</reference>
</references>
<references title="Informative References">
&ascii;
<reference anchor="SCRYPT">
<front>
<title>Stronger key derivation via sequential memory-hard
functions</title>
<author initials="C." surname="Percival" fullname="C. Percival"/>
<date month="May" year="2009" />
</front>
<seriesInfo name="BSDCan'09"
value="http://www.tarsnap.com/scrypt/scrypt.pdf" />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-21 17:40:48 |