RFC Errata
Found 6 records.
Status: Verified (2)
RFC 7914, "The scrypt Password-Based Key Derivation Function", August 2016
Source of RFC: IETF - NON WORKING GROUPArea Assignment: sec
Errata ID: 5871
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2019-10-07
Verifier Name: Benjamin Kaduk
Date Verified: 2019-10-10
Section 7.1 says:
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
It should say:
Module-scrypt-0 {1 3 6 1 4 1 11591 4 10}
DEFINITIONS ::= BEGIN
IMPORTS
ALGORITHM-IDENTIFIER
FROM PKCS5v2-0 -- [RFC2898]
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-5(5) modules(16) pkcs5v2-0(1) } ;
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
Notes:
The ASN.1 module does not compile without some minor corrections.
First, ALGORITHM-IDENTIFIER needs to be defined. The simplest solution is to IMPORT it from RFC 2898.
Second, the module name and the scrypt-params structure name must begin with capital letters. Small changes are made to meet these ASN.1 requirements.
Errata ID: 6972
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Gacel Perfinian
Date Reported: 2022-05-11
Verifier Name: Paul Wouters
Date Verified: 2024-01-17
Section 2 says:
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.
It should say:
At the current time, r=8 and p=1 appears to yield good results, but as memory latency decrease and CPU parallelism increase, it is likely that the optimum values for both r and p will increase.
Notes:
The wording in itself is a bit unclear, but the phrase "but as memory latency and CPU parallelism increase" might be interpreted as "but as memory latency increase and CPU parallelism increase", which in combination with the following phrase "it is likely that the optimum values for both r and p will increase" is inconsistent with how scrypt operates. All other things being equal (including but not limited to the parameters used and CPU or ASIC performance), the scrypt algorithm have an inverse-proportional relationship to memory latency, especially if the low-latency memory can contain all of the temporary computational data the algorithm needs.
Paul Wouters(AD): This seems correct, but as scrypt has been surpassed by argon2 (RFC9106) marked as Verified as no document update is expected for scrypt.
Status: Reported (4)
RFC 7914, "The scrypt Password-Based Key Derivation Function", August 2016
Source of RFC: IETF - NON WORKING GROUPArea Assignment: sec
Errata ID: 5971
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Tobias Nießen
Date Reported: 2020-02-02
Section 2 says:
The CPU/Memory cost parameter N ("costParameter") must be larger than 1, a power of 2, and less than 2^(128 * r / 8).
It should say:
The CPU/Memory cost parameter N ("costParameter") must be larger than 1, and a power of 2.
Notes:
The presented limit on N was incorrectly derived from the original scrypt publication. The correct theoretical upper limit on N is 2^(128 * r) for r < 5, and 2^512 for all other values of r. Thus, the least upper bound is 2^128, which far exceeds all possible values for N in the foreseeable future, making the limit irrelevant for current implementations.
Errata ID: 5972
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Tobias Nießen
Date Reported: 2020-02-02
Section 5 says:
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).
It should say:
Input:
r Block size parameter.
B Input octet vector of length 128 * r octets.
N CPU/Memory cost parameter, must be larger than 1,
and a power of 2.
Notes:
The presented limit on N was incorrectly derived from the original scrypt publication. The correct theoretical upper limit on N is 2^(128 * r) for r < 5, and 2^512 for all other values of r. Thus, the least upper bound is 2^128, which far exceeds all possible values for N in the foreseeable future, making the limit irrelevant for current implementations.
Errata ID: 5973
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Tobias Nießen
Date Reported: 2020-02-02
Section 6 says:
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.
It should say:
Input:
P Passphrase, an octet string.
S Salt, an octet string.
N CPU/Memory cost parameter, must be larger than 1,
and a power of 2.
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.
Notes:
The presented limit on N was incorrectly derived from the original scrypt publication. The correct theoretical upper limit on N is 2^(128 * r) for r < 5, and 2^512 for all other values of r. Thus, the least upper bound is 2^128, which far exceeds all possible values for N in the foreseeable future, making the limit irrelevant for current implementations.
Errata ID: 6452
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: John Comeau
Date Reported: 2021-03-05
Section 5 says:
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.
It should say:
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[r] ... B[r + 3] as a
little-endian integer.
Notes:
The original description of Integerify looks, to a programmer, as though a single byte (the final octet) is being converted to an integer (as with the Python `ord` operation). But that wouldn't make sense with the term "little-endian", which has meaning only with multiple-byte words. So the likely conclusion would be that this was a typographical error, and that the entire string X (or B) should be treated as an integer [e.g., Python3 int.from_bytes(b'\xff\xff\xff\xff\xff\xff\xff\xff', 'little')]. However, this interpretation of Integerify gives results that do not match the test vectors.
By looking at other people's code (https://github.com/ricmoo/pyscrypt in particular) I found that using the 4 bytes beginning halfway through the octet string gives results which do match the test vectors.