1

I'm looking at using Scrypt as a KDF. Assume the following:

  • the input will always be high-entropy random bytes generated by a CSPRNG
  • the length of the input can vary from between 8 to 32 bytes
  • the input-bytes are never re-used for generating another key
  • the salt is also generated by a CSPRNG
  • dklen (aka, output key length) can var from 64 bits to 1024 bits, depending on the algorithm for which the key is being used)
  • the cpu/memory/parallelization difficulty factors are user-defined, obviously with higher values resulting in higher security, but more processing time. These factors are set at the client's discretion
  • all key-expansion happens client-side
  • please don't be concerned with the practicalities of implementing such a system, it's beyond the scope of this question

Assuming that brute-force attacking a KDF is faster than brute-forcing the key itself, I understand that more KDF processing-time equates to more protection from such attacks. However, I've seen recommendations such as HKDF and KBKDF (discussed here), however I'm hesitant to use one of these protocols for various reasons (they're less-widely used/recognized, there isn't a lot of source code around for them, etc). Would Scrypt be a good fit for this scenario? Does it have any weak points, in which other protocols would be stronger?

Community
  • 1
hunter
  • 4,051
  • 6
  • 29
  • 42

1 Answers1

3

If you have a high entropy input, then scrypt isn't a good choice. It's purpose is to compensate for the low entropy of a password. Don't ask the user for memory/cpu factors, you don't need them if the input is high entropy. You don't need a salt either.

Simply use an input of at least 16 bytes from a secure random number generator.

I recommend using one of the following:

  • PBKDF2 with a single iteration. This is actually what scrypt uses internally to consume the input and produce the output.
  • HKDF - It's a very nice and simple design, standardized by NIST, has a RFC. Implementing it on top of HMAC-SHA-2 is trivial. It's my first choice as a KDF if the input has high entropy.
CodesInChaos
  • 25,121
  • 2
  • 90
  • 129