Okay so I have two options for how I would derive two keys for AES encryption and HMAC they are as follows:

  1. Run BCrypt on a users passphrase and then use the bouncy castle implementation of HKDF in java to extend the key from 31-bytes to 64-bytes before then splitting the result into two 32-byte keys.

  2. Run Bcrypt twice on a users passphrase with a different salt and then use the bouncy castle implementation of HKDF in java to extend both keys from 31-bytes to 32-bytes.

My question is which way is better? (more secure)

Note: If you do have a answer please leave your reasoning in a way that is easy to understand.

  • 1
    $\begingroup$ 2. doesn't buy you anything, as the attacker only needs to break one. Also, can't bcrypt output 64 bytes? $\endgroup$ – user13741 Nov 14 '14 at 16:57

In both options, if the adversary has a way to check either AES key, then a brute password guessing attack can be attempted, and BCrypt is the main line of defense against that.

For constant effort, option 2 force to halve the cost parameter in BCrypt, and is thus twice more vulnerable to password guessing than option 1 is.

BCrypt's output is described as 31 byte, and likely has 192 bits of entropy excluding cost and salt. If so, this is more entropy than needed for security in the foreseeable future, and acceptable baring a diktat requirement that all keys have some larger size.

Thus option 1 is decidedly the best of the two; however a proper implementation of scrypt would be considerably safer, and as a bonus there is no need for something extra in order to generate the desired amount of key material.

| improve this answer | |
  • $\begingroup$ Thanks for your suggestions I have decided on using SCrypt instead :) $\endgroup$ – HighAsAKite Nov 17 '14 at 18:56

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.