[davidhollander]

Why is bcrypt better than simply recursively hashing SHA512 ~2^11 times to produce an equivalent work factor?

Assume wall time is held constant at 1 second per password using both methods: is there an entropy loss or weakness associated with recursive hashing that bcrypt avoids?

[eneveu]

What you are referring to is called "stretching". It's a lot better than a simple salted hash, but bcrypt would still be better.

I'm no crypto expert, but I think this is due to the way bcrypt was designed, and their use of a pessimized Blowfish cypher. SHA512 was designed for speed, which is the opposite of what you want with a password hashing scheme.

tptacek talks a little about this in this blog post:

http://chargen.matasano.com/chargen/2007/9/7/enough-with-the...

"Bcrypt uses Blowfish instead of MD5. Blowfish is a block cipher with a notoriously expensive setup time. To optimize Blowfish to run much faster, you’d have to contribute a major advance to cryptography. We security practioners are all “betting people”, and we usually like to place our bets on the side that “demands major advances in cryptography”."

Other interesting links: http://stackoverflow.com/questions/3722780/do-any-security-e... http://en.wikipedia.org/wiki/Bcrypt

[tzs]

Something doesn't make sense in that blog entry you cite. He says:

   Now let’s re-explain rainbow tables:

   1. take a “dictionary” —- say, of all combinations of alphanumerics
   less than 15 characters

   2. hash all of them

   3. burn the results onto a DVD.

   You now have several hundred billion hash values that you
   can reverse back to text —- a “rainbow table”.

Alphanumeric usually means either 36 or 62 possible characters. Let's take 36. Then there are 36^14 possible 14 character alphanumeric passwords. (He said less than 15, so we should also consider 13 characters, 12 characters, and so on, so this is going to come out a little low since I'm just doing 14 exactly). That's 6.14 x 10^21 possible passwords.

If you could compute 10 billion hashes/second, that would take 20000 years. (41 million years if mixed case alphanumeric is allowed). Could anyone REALLY make a table covering all 14 character or less alphanumerics in 2007, and fit it on DVD?

I believe there were tables for 14 character Windows passwords then, but due to poor design Windows passwords were in effect treated as two 7 character passwords. You just needed tables that covered the hashes of all 7 character passwords, which is a lot more tractable. Could that be what the author was thinking of?

[eneveu]

I think Thomas was simplifying rainbow tables in his post, to make it more understandable. In practice, you wouldn't use all combination of alphanumerics. You would use a dictionary. This greatly restricts the search space.

http://en.wikipedia.org/wiki/Rainbow_table http://en.wikipedia.org/wiki/Dictionary_attack

[tptacek]

Look at PBKDF2:

http://www.ietf.org/rfc/rfc2898.txt