9

I read a lot of entries at stack exchange about bcrypt and why it is supposed to be better than PBKDF2 in terms of password storage.

I'm asking now if bcrypt is better than PBKDF2 in terms of key derivation? In my case, I only have to derive a symmetric key for AES encryption (e.g. 256 bits key length). This key doesn't have to be saved, it's only used on the fly for encryption. What would you suggest, is bcrypt better in this scenario than PBKDF2?

Cheers, Pits

Community
  • 1
Pits
  • 91
  • 2

1 Answers1

7

Bcrypt outputs a 192-bit result, no more, no less. This is inconvenient if you want a key longer than 192 bits, e.g. a 256-bit AES key. In that situation, I recommend taking the bcrypt output and hashing it with a secure hash function with a large enough output for the required key material length (e.g. if you need a 256-bit encryption key and a 128-bit MAC key, use SHA-384 or SHA-512). Otherwise, bcrypt is considered to be fine as far as key derivation is concerned.

(Generating a 256-bit encryption key from a 192-bit value does not make much sense; but using 256-bit AES instead of 128-bit AES does not make much sense either, practically speaking. The real weakness in a bcrypt-powered system, anyway, is that the keys come from a human-remembered password; bcrypt makes such a thing tolerable, but nowhere near as secure as a truly random 128-bit key, much less a 192-bit or 256-bit key. So if you need a 256-bit key for "administrative reasons", generating that from the bcrypt output and a hash function would create no extra actual security problem.)

Bcrypt has a minor quirk in that if you split a 192-bit bcrypt output into three 64-bit values, it is mathematically guaranteed that the three 64-bit values will be distinct from each other. Thus, the output of bcrypt can be distinguished from that of a random oracle by looking at about 264 distinct bcrypt outputs (for random 192-bit values, one may expect to encounter a block collision -- two of the three 64-bit values equal to each other -- after an average of 264/3 values). This is a very slight bias which has no practical consequence for security.

Community
  • 1
Thomas Pornin
  • 322,884
  • 58
  • 787
  • 955
  • Interesting quirk – makerofthings7 Jan 24 '12 at 15:46
  • Thanks for your answer. Obviously you are right that a 256 AES is not needed if the key is derived using bcrypt. A password chosen by a person is always much more insecure that a machine-generated 128 bit key... – Pits Jan 24 '12 at 16:07