Description
See: https://tools.ietf.org/html/rfc7914. In particular, Section 2: scrypt Parameters:
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).
go-ethereum test data: https://github.com/ethereum/go-ethereum/blob/master/accounts/keystore/testdata/v3_test_vector.json#L13-L15.
Parameters {N: 262144, r: 1, p: 8}
are not valid for an RFC-compliant implementation of scrypt.
Can someone on the geth team shed light on why geth's usage of scrypt is not compliant with the RFC? Was/is it a deliberate decision or an accident?
Context re: why I'm filing this issue: nodejs/node#28799 (comment).
geth's test data has long been adapted for use in test suite's of tools for other runtimes. For example, see: https://github.com/ethereum/web3.js/blob/1.x/test/eth.accounts.encrypt-decrypt.js#L32-L34. The PR that landed that test script/data was made in mid 2017. Likewise, implementations of scrypt (for those other runtimes; example: scryptsy) that are used to build Ethereum tooling don't adhere to the RFC.
In the case of Node.js, per the GitHub comment linked above, the built-in RFC-compliant scrypt
can't handle the N, r, p combination in the test data.