Sorry for this ignorant question but I am currently weighing up the advantages and disadvantages of BCrypt over PBKDF2 and from what I have read BCrypt is considered more secure but from what I have discovered BCrypt only derives as 248-bit key (Example: E2cP18g8DyWwg3emgpHOaPBZzrcRVrO) and the rest of it is the salt, however I require a 512-bit key so I can split it into two sub-keys on for a AES encryption key and the other for HMAC generation.

Would it be secure to take the sha-512 hash of the key produced by BCrypt and split that or should I just keep using PBKDF2?

  • $\begingroup$ Do you have a reference for the 248-bit number? $\endgroup$
    – mikeazo
    Commented Nov 11, 2014 at 19:39
  • $\begingroup$ Why not just run bcrypt twice with a different salt? $\endgroup$
    – mikeazo
    Commented Nov 11, 2014 at 19:40
  • $\begingroup$ @mikeazo because the 248 bit key would still be to small for a AES-256 encryption key and I'm not sure if this is what you asked for but when I run bcrypt it returns {salt}{248-bit key} $\endgroup$ Commented Nov 11, 2014 at 19:43
  • $\begingroup$ First, the output of bcrypt is not a 248-bit key. It is 192-bit value encoded as base-64, which is why it is 248-bits. What are your requirements for the 512-bit key. Just that it is 512-bits long and uniformly distributed? Or do you require that it have a certain amount of entropy? Or is there something else? I'm assuming you are considering bcrypt and pbkdf2 so that brute force is slow. Is that correct? $\endgroup$
    – mikeazo
    Commented Nov 11, 2014 at 20:00
  • $\begingroup$ @mikeazo yes I did consider using PBKDF2 or Bcrypt fot that exact reason my only requirement is that it is 512-bits long and would be suitable for encrypting a file and generating a hmac of said encrypted file (One 256-bit of the key would be used as a encryption key the other as a hmac key) $\endgroup$ Commented Nov 11, 2014 at 20:15

2 Answers 2


BCrypt is considered more secure

The theoretical security of bcrypt has received less scrutiny than that of PBKDF2, SHA2 and HMAC. PBKDF2 is thus widely standardised (e.g. in NIST SP800-132 and PKCS #5) while bcrypt is not.

In practice the security (resistance to brute force attack or dictionary attack) of bcrypt and PBKDF2-HMAC-SHA512 can be controlled by a workload parameter. bcrypt is more secure than PBKDF2 in the sense that: if you select the workload parameters such that the algorithms use the same computing time on a general-purpose CPU, then an attacker able to choose their hardware (CPU, GPU, FPGA, or ASIC) can attack PBKDF2 4 to 6 times more effectively than bcrypt at the same cost (see the scrypt paper).

As a heuristic we could say that a password hashed with PBKDF2 should have 2 to 3 bits more randomness than a password hashed with bcrypt to achieve equivalent security (against a brute force attack; for equivalent workload parameters).

Would it be secure to take the sha-512 hash of the key produced by BCrypt and split that

No, but you're on the right path by splitting the operation into a step that produces a key, and a step that expands the key. The trick is to select the right primitives for these operations.

To expand a key - that is, to produce using one key a stream of derived random output suitable for use as key material - you need a Pseudorandom Function Family (PRF). SHA-512 is not a PRF, but HMAC-SHA512 is. Using HMAC-SHA512 would be a secure - but not ideal - solution.

A better solution is to use HKDF which splits key derivation into extraction and expansion steps. By using bcrypt or PBKDF2 you have already extracted a pseudorandom key (HKDF calls this a PRK) from the password. You can apply the HKDF expansion step to that PRK to produce derived keying material of any length; equivalently you could use one of the Key Derivation Functions from NIST SP800-108.

See also Do any security experts recommend bcrypt for password storage? for more on PBKDF2 vs bcrypt.


Yes you can use bcrypt in this scenario. The output of bcrypt is 192-bits encoded using base-64, giving you 248-bits. Well short of your 512-bit requirement.

What I would recommend you do, if you choose bcrypt, is akin to what was recommended here. Use HMAC instead of SHA-512 of the output of bcrypt. For the reasons why, see this question and answer. It is important to understand though that since the output of crypt is smaller than 256-bits, neither of your keys will have 256-bits of entropy. It sounds like you aren't too worried about that though.

As to bcrypt in this manner vs. simply using PBKDF2 with SHA-512, that depends on what you are worried about. PBKDF2 can more easily be attacked using things like GPUs and FPGAs.

  • $\begingroup$ One final question so im sure I understand completely so would i? 1:Generate a "Master Key" using Bcrypt. 2:Then split the master key. 3:Use one half of the "master key" as a HMAC-SHA512 key to generate the encryption key. 4:Use the other half of the "master key" as a HMAC-SHA512 key to generate the key for the actual HMAC of the encrypted data? $\endgroup$ Commented Nov 11, 2014 at 20:26
  • $\begingroup$ No, use the entire master key for both, but use a different "message" for HMAC. $\endgroup$
    – mikeazo
    Commented Nov 11, 2014 at 22:19

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.