Everyone is comparing bcrypt to scrypt. Bcrypt is proven, lots of cryptoanalysis and no vulnerabilities so far, but uses very low memory. While scrypt uses a lot of memory, but it's too early in its life. Is there anything problematic by using them in cascade/together? Like scrypt the password then bcrypt the result. Eg.: bcrypt(scrypt(pwd))

Is this a problematic approach somehow or everyone just tries to solve one problem with one and only one KDF?

  • $\begingroup$ Wouldn't such construction vulnerable to the Meet in the Middle Attack? $\endgroup$
    – ddddavidee
    Oct 5 '14 at 16:37
  • $\begingroup$ @ddddavidee: no, it wouldn't, as bcrypt (the outer transform) cannot be inverted. $\endgroup$
    – poncho
    Oct 5 '14 at 16:56
  • $\begingroup$ ah, yes! you should build a dictionary to inverse it (infeasible). thank you! $\endgroup$
    – ddddavidee
    Oct 5 '14 at 16:57

Probably because a simple cascade would only be stronger against some attacks, while opening the door to more implementation bugs.

While bcrypt and scrypt are password-hashing functions, much of what is in the answers to this question about combining hash functions applies here. Different constructions give preimage resistance and PRF-ness, and which is desired depends somewhat on the use case. (Password storage is mostly about the former, while the latter also matters if you are deriving an encryption key with scrypt.)

Regarding implementation bugs, if the inner function, which is applied to the raw password, leaks the input through some side channel attack, the outer function may not matter at all. Conversely, if the outer function somehow leaks its output, then using the cascade for encryption keys may be completely broken, and using it for password storage may e.g. allow offline attacks.

With password hashing there's the additional problem of how to divide the time. If you spend the same time on both bcrypt and scrypt, a dedicated attack using ASICs or GPUs could be almost twice as fast as if you spent all that time on scrypt.

All that aside, scrypt is already basically a cascaded algorithm. Internally it uses PBKDF2 to preprocess the input and to produce the final output data. Its preimage resistance should therefore be at least equal to that of a single round of PBKDF2, i.e. HMAC with SHA-256.

  • 1
    $\begingroup$ One minor nit-pick: bcrypt is not a key-derivation function. You cannot use bcrypt to, for example, generate 256 bits of key material. bcrypt always outputs 24-bytes (the result of encrypting OrpheanBeholderScryDoubt with Blowfish encryption). Scrypt on the other hand is a (password based) key derivation function; which people have used for password storage. $\endgroup$
    – Ian Boyd
    Aug 14 '15 at 20:42
  • $\begingroup$ @IanBoyd you could hash the output to get a key, but yes, it's not meant for key-derivation. I'll rephrase. $\endgroup$
    – otus
    Aug 15 '15 at 6:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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