Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

crypto.scrypt fails with N > 16384 (logN > 14) #21524

Closed
chrisveness opened this issue Jun 25, 2018 · 5 comments
Closed

crypto.scrypt fails with N > 16384 (logN > 14) #21524

chrisveness opened this issue Jun 25, 2018 · 5 comments
Labels
crypto Issues and PRs related to the crypto subsystem. invalid Issues and PRs that are invalid.

Comments

@chrisveness
Copy link

With N = 16384 (logN = 14), crypto.scrypt works correctly:

$ node
> crypto.scryptSync('pw', crypto.randomBytes(32), 32, { N: 16384 })
<Buffer d6 2f 81 77 db bb 6f ab 27 56 91 1a eb fb d4 ee b0 89 43 1b e7 15 f1 2a f6 df bc 61 9a 79 1d 80>

With N = 32768 (logN = 15) and above, crypto.scrypt throws a 'memory limit exceeded' error:

$ node
> crypto.scryptSync('pw', crypto.randomBytes(32), 32, { N: 32768 })
Error: error:060B50AC:digital envelope routines:EVP_PBE_scrypt:memory limit exceeded
    at handleError (internal/crypto/scrypt.js:62:14)
    at Object.scryptSync (internal/crypto/scrypt.js:55:3)

I have confirmed Colin Percival's implementation will go to N = 4194304 (logN = 22).

@bnoordhuis
Copy link
Member

It's in the docs, see the maxmem parameter:

- `options` {Object}
  - `N` {number} CPU/memory cost parameter. Must be a power of two greater
                 than one. **Default:** `16384`.
  - `r` {number} Block size parameter. **Default:** `8`.
  - `p` {number} Parallelization parameter. **Default:** `1`.
  - `maxmem` {number} Memory upper bound. It is an error when (approximately)
                      `128*N*r > maxmem` **Default:** `32 * 1024 * 1024`.

@bnoordhuis bnoordhuis added invalid Issues and PRs that are invalid. crypto Issues and PRs related to the crypto subsystem. labels Jun 25, 2018
@addaleax
Copy link
Member

Shouldn’t it be 128*N*r >= maxmem in that case? Or does that distinction not matter?

@bnoordhuis
Copy link
Member

The "(approximately)" is because openssl uses a slightly different formula than the standard one: 128*p*r + 128*(2+N)*r.

I decided to leave it alone because the difference is a few kilobytes unless p is very large. I figured a full explanation wouldn't be informative, just distracting trivia.

@chrisveness
Copy link
Author

I misread the docs! thank you.

(docs are slightly misformatted at the moment).

@boutell
Copy link

boutell commented Apr 15, 2024

Sorry to necro-comment, but a silly question: why is maxmem not determined automatically from the other parameters using the above formula? What is the benefit of not doing so?

For now I'm automating that parameter based on the equation given above:

128*p*r + 128*(2+N)*r

So that developers can set the others and get the intended result.

Maybe the goal of explicit maxmem is to make sure people realize the resources that could be taken up?

The settings recommended by OWASP do work out to a rather high maxmem:

"If Argon2id is not available, use scrypt with a minimum CPU/memory cost parameter of (2^17), a minimum block size of 8 (1024 bytes), and a parallelization parameter of 1"

That works out to 134220800, around 134MB. Pricey, but here we are in 2024.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
crypto Issues and PRs related to the crypto subsystem. invalid Issues and PRs that are invalid.
Projects
None yet
Development

No branches or pull requests

4 participants