# RFC Errata

Found 6 records.

## Status: Verified (1)

### 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.

## Status: Reported (5)

### 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.

Errata ID: 6972

**Status: Reported
Type: Technical
Publication Format(s) : TEXT**

Reported By: Gacel Perfinian

Date Reported: 2022-05-11

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.