1
$\begingroup$

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?

Improve this question
$\endgroup$
5
  • $\begingroup$ I do not get the input will always be high-entropy random bytes generated by a CSPRNG. The P in CSPRNG is for Pseudo, hence there is no more (possibly less) entropy in the output of a CSPRNG as there is in its input. Also, with a high-entropy input, why use Scrypt or other slow KDF, which is intended for low-entropy input? $\endgroup$
    – fgrieu ♦
    Commented Feb 15, 2013 at 19:35
  • $\begingroup$ @fgrieu - assume (as stated in my question) that the input could be as short as 8 bytes. I reasoned that using something other than a slow kdf (such as a simple sha256 hash) would be too easy to brute-force (yes, even though the input is high entropy). Instead of asking me "why use Scrypt?", why don't you tell me why not (which is really what the question was asking in the first place). $\endgroup$
    – hunter
    Commented Feb 15, 2013 at 20:27
  • $\begingroup$ Ah, did not read well enough. Indeed, with an 8-byte input, Scrypt is a good idea. Still "high-entropy" is contradictory and misleading. $\endgroup$
    – fgrieu ♦
    Commented Feb 15, 2013 at 21:48
  • $\begingroup$ @fgrieu - would you mind explaining what you mean by 'high-entropy' being contradictory and misleading? I understand that the 'P' in CSPRNG stands for Psuedo, but I also know that the 'CS' stands for Cryptographically Secure. Are you suggesting that the output of a CSPRNG could be predictable to the point of compromising a key? $\endgroup$
    – hunter
    Commented Feb 19, 2013 at 15:03
  • $\begingroup$ A CSPRNG (at least in its standard definition) is a deterministic function of its input. There can be no more entropy in its output than there is in its input, because the number of possible outputs (truncated to any given length) can be no more than the number of possible inputs. 256 bits output by a CSPRNG may have little entropy, if there is little in the seed. This output could be guessed, if the seed can. This is a frequent accident. $\endgroup$
    – fgrieu ♦
    Commented Feb 19, 2013 at 21:00

1 Answer 1

Reset to default
3
$\begingroup$

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.
Improve this answer
$\endgroup$
4
  • $\begingroup$ thanks for the practical advice. I'll look into HKDF, as I've already got a functional implementation of HMAC-SHA256. Also, regarding the salt - you're right - good catch! $\endgroup$
    – hunter
    Commented Feb 15, 2013 at 20:33
  • $\begingroup$ if the input was as short as 8 bytes (still high entropy), would you still advise against using Scrypt? $\endgroup$
    – hunter
    Commented Feb 21, 2013 at 19:25
  • 2
    $\begingroup$ @hunter No, with 8 bytes I'd use scrypt. My definition of "high entropy" is "at least 128 bits of entropy", and it's mathematically impossible for 8 bytes to have such high entropy even when they're perfectly random. $\endgroup$
    – CodesInChaos
    Commented Feb 21, 2013 at 19:40
  • $\begingroup$ thanks for the context - it's always helpful to know the 'why' instead of just the 'how to' $\endgroup$
    – hunter
    Commented Feb 21, 2013 at 19:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.