Why don't we use bcrypt and scrypt together?

Question

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?

Answer 1

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.