One document matched: draft-josefsson-scrypt-kdf-05.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC0020 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.0020.xml'>
<!ENTITY RFC2898 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2898.xml'>
<!ENTITY RFC4086 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4086.xml'>
<!ENTITY RFC5208 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5208.xml'>
<!ENTITY RFC5958 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5958.xml'>
<!ENTITY RFC6234 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6234.xml'>
]>
<?rfc compact="no"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<rfc category="info" ipr="trust200902"
docName="draft-josefsson-scrypt-kdf-05">
<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 year="2016"/>
<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 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, <xref target="RFC2898">PKCS#5 PBKDF2</xref>
(typically used with SHA-1), <xref target="SHA2CRYPT">GNU
SHA-256/512 crypt</xref>, <xref target="NTLM">Windows NT LAN
Manager (NTLM)</xref> hash, and the Blowfish-based <xref
target="BCRYPT">bcrypt</xref>. 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.</t>
<t>All password-based key derivation functions mentioned above
share the same weakness against powerful attackers. 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. 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.</t>
<t>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>This document do not introduce scrypt for the first time.
The original <xref target="SCRYPT">scrypt paper</xref> was
published as a peer-reviewed scientific paper, and contains
further background and discussions.</t>
<t>The purpose of this document is to serve as a stable
reference for IETF 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.</t>
</section>
<section anchor="scrypt-parameters"
title="Scrypt Parameters">
<t>
The scrypt function takes several parameters. The passphrase
P is typically a human-chosen password. The salt is normally
uniquely and randomly generated <xref target="RFC4086"/>. The
parameter r ("blockSize") specify 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"), a
positive integer less than or equal to ((2^32-1) * 32) / (128
* r). The intended output length dkLen in octets of the
derived key ("keyLength"); a positive integer less than or
equal to (2^32 - 1) * 32.
</t>
<t>
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, taking
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.
</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 section 8 of
<xref target="SALSA20SPEC" /> for its specification, and <xref
target="SALSA20CORE" /> for more information. The algorithm
description, in C language, is included below as a stable
reference, without endianness conversion and alignment.</t>
<figure>
<artwork><![CDATA[
#define R(a,b) (((a) << (b)) | ((a) >> (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];
}
]]></artwork>
</figure>
</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[1] || ... || B[2 * r - 1]
Input octet string (of size 128 * r octets),
treated as 2 * r 64-octet blocks,
where each element in B is a 64-octet block.
Output:
B'[0] || B'[1] || ... || B'[2 * r - 1]
Output octet string.
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. Initialize an array B consisting of p blocks of 128 * r octets each:
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. 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.</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>
<t>To be usable in <xref target="RFC5208">PKCS#8</xref> and
<xref target="RFC5958">Asymmetric Key Packages</xref> the
following extension of the PBES2-KDFs type is needed.</t>
<figure>
<artwork><![CDATA[
PBES2-KDFs ALGORITHM-IDENTIFIER ::=
{ {scrypt-params IDENTIFIED BY id-scrypt}, ... }
]]></artwork>
</figure>
<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
}
PBES2-KDFs ALGORITHM-IDENTIFIER ::=
{ {scrypt-params IDENTIFIED BY id-scrypt}, ... }
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="RFC0020">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="RFC0020">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="pkcs8-test-vectors"
title="Test Vectors for PKCS#8">
<t><xref target="RFC5208">PKCS#8</xref> and <xref
target="RFC5958">Asymmetric Key Packages</xref> 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.</t>
<figure>
<artwork><![CDATA[
-----BEGIN ENCRYPTED PRIVATE KEY-----
MIHiME0GCSqGSIb3DQEFDTBAMB8GCSsGAQQB2kcECzASBAVNb3VzZQIDEAAAAgEI
AgEBMB0GCWCGSAFlAwQBKgQQyYmguHMsOwzGMPoyObk/JgSBkJb47EWd5iAqJlyy
+ni5ftd6gZgOPaLQClL7mEZc2KQay0VhjZm/7MbBUNbqOAXNM6OGebXxVp6sHUAL
iBGY/Dls7B1TsWeGObE0sS1MXEpuREuloZjcsNVcNXWPlLdZtkSH6uwWzR0PyG/Z
+ZXfNodZtd/voKlvLOw5B3opGIFaLkbtLZQwMiGtl42AS89lZg==
-----END ENCRYPTED PRIVATE KEY-----
]]></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"/>. The PKCS#8 test
vector was provided by Stephen N. Henson.</t>
<t>Feedback on this document were received from Dmitry
Chestnykh, Alexander Klink, Rob Kendrick, Royce Williams Ted
Rolle, Jr., Eitan Adler, Stephen Farrel, Nikos
Mavrogiannopoulos, and Paul Kyzivat.</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, 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.</t>
<t>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>
<t>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.</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2898;
&RFC6234;
</references>
<references title="Informative References">
&RFC0020;
&RFC5208;
&RFC5958;
&RFC4086;
<reference anchor="SALSA20SPEC">
<front>
<title>Salsa20 specification</title>
<author initials="D.J." surname="Bernstein"
fullname="D.J. Bernstein"/>
<date month="April" year="2005" />
</front>
<seriesInfo name="WWW" value="http://cr.yp.to/snuffle/spec.pdf" />
</reference>
<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>
<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>
<reference anchor="BCRYPT">
<front>
<title>A Future-Adaptable Password Scheme</title>
<author initials="N." surname="Provos" fullname="N. Provos"/>
<author initials="D." surname="Mazières" fullname="D. Mazières"/>
<date month="June" year="1999" />
</front>
<seriesInfo
name="USENIX 1999"
value="https://www.usenix.org/legacy/event/usenix99/provos/provos.pdf" />
</reference>
<reference anchor="NTLM">
<front>
<title>[MS-NLMP]: NT LAN Manager (NTLM) Authentication
Protocol</title>
<author fullname="Microsoft"/>
<date year="2015" />
</front>
<seriesInfo
name="Microsoft"
value="https://msdn.microsoft.com/en-us/library/cc236621.aspx" />
</reference>
<reference anchor="SHA2CRYPT">
<front>
<title>Unix crypt using SHA-256 and SHA-512</title>
<author initials="U." surname="Drepper" fullname="U. Drepper"/>
<date month="April" year="2008" />
</front>
<seriesInfo name="URL"
value="http://www.akkadia.org/drepper/SHA-crypt.txt" />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-21 17:40:45 |