What are recommended / minimum parameters for hashlib.scrypt?

Question

The documentation of hashlib.scrypt is a bit short:

hashlib.scrypt(password, *, salt, n, r, p, maxmem=0, dklen=64)

The function provides scrypt password-based key derivation function as defined in RFC 7914.

password and salt must be bytes-like objects. Applications and libraries should limit password to a sensible length (e.g. 1024). salt should be about 16 or more bytes from a proper source, e.g. os.urandom().

n is the CPU/Memory cost factor, r the block size, p parallelization factor and maxmem limits memory (OpenSSL 1.1.0 defaults to 32 MiB). dklen is the length of the derived key.

I figured out that n must be a power of 2 and at least 2.

Besides that, I feel a bit left alone. Would hashlib.scrypt(b"foo", salt=b"bar", n=2, r=1, p=1) be considered safe today? How do I judge which parameters to take?

Answer 1

I was recently using hashlib.scrypt and I was also stumped what all these parameters minimum and maximum values were. You have likely answered your question, but I wanted to share my research just in case if you still have some open questions about these parameters.

As you previously stated the documentation for hashlib.scrypt lacks a solid explanation or these parameters even for Python 3.11

RFC7914 - The scrypt Password-Based Key Derivation Function is also lite on details:

scrypt Parameters

The scrypt function takes several parameters. The passphrase P is typically a human-chosen password. The salt is normally uniquely and randomly generated [RFC4086]. The parameter r ("blockSize") specifies 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") is a positive integer less than or equal to ((2^32-1) * 32) / (128 * r). The intended output length dkLen is the length in octets of the key to be derived ("keyLength"); it is a positive integer less than or equal to (2^32 - 1) * 32.

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

I found another reference, which explained these parameters in greater detail.

The Scrypt config parameters are:

• parameter N – iterations count (affects memory and CPU usage), e.g. 16384 (2 ** 14) or 2048 (2 ** 11)

• parameter R - block size (affects memory and CPU usage), e.g. 8

• parameter P – parallelism factor (threads to run in parallel - affects the memory, CPU usage), usually 1

• parameter password – the input password (8-10 chars minimal length is recommended). But you should use long and complex password to avoid password cracking attacks.

• parameter salt – securely-generated random bytes (64 bits minimum, 128 bits recommended)

• parameter derived-key-length(dklen) - how many bytes to generate as output, e.g. 32 bytes (256 bits)

The source states:

Choosing parameters depends on how much you want to wait and what level of security (password cracking resistance) do you want to achieve:

Sample parameters for interactive login: N=16384, r=8, p=1 (RAM = 2 MB). For interactive login you most probably do not want to wait more than a 0.5 seconds, so the computations should be very slow. Also at the server side, it is usual that many users can login in the same time, so slow Scrypt computation will slow down the entire system.

Sample parameters for file encryption: N=1048576, r=8, p=1 (RAM = 1 GB). When you encrypt your hard drive, you will unlock the encrypted data in rare cases, usually not more than 2-3 times per day, so you may want to wait for 2-3 seconds to increase the security.