0

i need bcrypt to create encryption keys and also for authentication hashes, but entropy of delivered output from password has to be >256bit (which clearly can't be achieved by hashing 196bits with SHA256).

is there any bcrypt implementation that use SHA256 in KDF? if not please help me how to do that myself

Scrypt is more preferred but android phones don't have that much RAM. is there anyway to use low RAM in Scrypt?)

Adi
  • 43,953
  • 16
  • 137
  • 168
KDF
  • 1
  • 2
  • 1
    Yes, but that's the only way to get a 256 bit value from a bcrypt output. Use `PBKDF2` if you want a tunable output length instead. –  Dec 19 '13 at 14:35
  • I agree with Terry, either use PBKDF2 or apply a SHA-256 to your bcrypt algorithm – Lucas Kauffman Dec 19 '13 at 14:47
  • What kind of user do you expect? Users who invent epic pass poems? I've never seen a password with 200 bits of entropy. – CodesInChaos Dec 19 '13 at 15:17

1 Answers1

6

By construction, bcrypt is its own function, and does not use a hash function like SHA-1 or SHA-256. You may be confusing it with PBKDF2.

Your requirement on "entropy" is, at best, severely misguided:

  • As long as your attackers cannot convert the whole mass of the complete friggin' Galaxy into energy to run some humongous computation, 256 bits of entropy are the Mother of all Overkill. For any practical situation which does not involve battling with hostile extraterrestrial entities, 128 bits are more than enough.

  • You won't get 256 bits of entropy or even 128 bits. You said "bcrypt": thus, you are processing a password. A password which can be chosen and remembered by a human being cannot reach that much entropy. For typical users, you can consider yourself lucky if you reach, say, 32 bits of entropy; most people cannot do even that. No matter what you do and how many hash functions you throw at it, you will never get more entropy on the output than you had to begin with, entropy being "what the attacker does not know", i.e. the password.

    (The important point here is that entropy does not equate length.)

What you really want, here, is a password-processing function which extends a password into as many "key bits" as you need for whatever cryptographic purpose you envision. For instance, you want 256 bits because you do password-based encryption and need 128 bits for symmetric encryption itself, and 128 more bits for a MAC. This is done in two steps:

  1. Hash the password with a password-hashing function which includes the features specific to password protection, which are ways to cope with the inherent weakness of passwords. Namely, salts and configurable slowness. Bcrypt is fine for that. See this answer for details.

  2. Extend the password hash with a deterministic Key Derivation Function. If you just need 256 bits, then just hashing the password hash with SHA-256 is perfectly fine: SHA-256 works well as a KDF as long as you do not need more than 256 bits of output. For arbitrarily long outputs, you may need something a bit more complex; SSL/TLS's "pseudorandom function" is a thoroughly studied example.

    Beware that typical bcrypt implementations output a string which encodes the 192-bit output but also the salt and other parameters; for key extension, you want to process only the 192-bit output.

PBKDF2 is a "password-based key derivation function" (hence the name) which combines both operations.

Community
  • 1
Thomas Pornin
  • 322,884
  • 58
  • 787
  • 955
  • You don't know the capability of a quantum computer that exists in 20 years. You also can't forcast mathematical advances. If you want to encrypt something to be safe years into the future, than you can't say what happens to be overkill. – Christian Dec 20 '13 at 19:08
  • KeePass allows me to choose and remember 256 bit passwords as far as external services are concerned. It annoying when websites don't accept 256 bit passwords. – Christian Dec 20 '13 at 19:15