3

Suppose we throw a regular password into scrypt to generate some data. Scrypt allows us to specify how large the output data should be.

My question is, to take an extreme case, if we ask for a 1 GB data from scrypt, would it be possible somehow quickly to generate the final bytes of this output from the first bytes?

In other words, is there a threshold "x bytes" at which I "should probably not ask scrypt for more than x bytes"?

Update: Let me put it a different way: If I tell scrypt to produce 1 GB of data, make the first x bytes of the result available to the public, and use the final 48 bytes (as key and IV) to encrypt sensitive data using AES-256-CBC, am I in trouble? Trouble, in the sense that I have defeated the purpose of using scrypt? Does the answer depend on x?

1 Answer 1

3

You should not ask for more output from scrypt than you need. The CPU/memory cost of scrypt hashing is not dominated by the output size, but rather by the setup process (in Wikipedia's explanation of the algorithm, the values "N" (CPU/memory cost) and "p" (parallelization parameter)). The output is generated by a single iteration of PBKDF2, using the values from the setup phase of scrypt as the salt.

For the same reason, generating partial output (say, the last few bytes) is only marginally faster than generating the entire output: it's possible to generate only selected subsets of the output of PBKDF2 at low cost, but you need the entire input to be available to do this.

PBKDF2 generates its output as a series of blocks by concatenating and iteratively hashing the password, seed, and 32-bit block number. For output of less than 2^32-1 blocks (128 GB for PBKDF2 as used by scrypt), revealing part of the output has no impact on the security of the rest of the output. After that point, however, the output starts repeating itself.

3
  • So what you're saying is that whether the attacker wants to know the last bytes or the first bytes (or any other bytes), or all the bytes, of the 1 GB output, he simply has to go through the setup phase - which should be the bottleneck anyway. So in this sense, talking about "generating the last bytes from the first bytes", although it can be done easily with a single iteration of PBKDF2, is predicated on the setup phase having been finished, so it's kind of pointless to be talking about it that way. Is that sort of what you mean? Jul 8, 2015 at 4:59
  • I have actually added an update to my original question. Are you able to answer that one specifically? Jul 8, 2015 at 7:06
  • @cryptonamus, answered.
    – Mark
    Jul 8, 2015 at 9:19

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .