1

I wonder what are the advantages of using bcrypt over an iterated and salted KDF based on some cryptographic hash function like SHA-1 (or SHA-3)? I guess the authors of bcrypt chose Blowfish (a block cipher) for a serious reason, but we could barely replace it in with SHA-1/SHA-3 (a hash function). What is wrong with such an approach? What are security properties brought by a block cipher that are not by hash functions?

matlink
  • 39
  • 3

2 Answers2

2

The bcrypt KDF does not use the entire block cipher as-is. It relies on a modified version of its key schedule. This is important because blowfish, unlike many other ciphers, has an extremely expensive key schedule. It requires about four kilobytes of fast memory, compared with SHA-1 which is so light that it can almost be computed entirely in x86 registers. Although bcrypt is not nearly as memory-hard as other, modern KDFs like Argon2, it was still quite good at the time and is still better in many ways than PBKDF2, which internally uses a hash function like SHA-1 or the SHA-2 family.

See Why can't one implement bcrypt in Cuda? for more information on why memory hardness is good. It explains why you can't get as much out of the massive parallelism of a GPU with bcrypt. There's also the wonderful answer by Thomas Pornin elsewhere which goes into more detail about bcrypt's security.

forest
  • 15,626
  • 2
  • 49
  • 103
1

A good way to find out what the authors meant would probably be reading their original paper where they introduced bcrypt : https://www.usenix.org/legacy/event/usenix99/provos/provos.pdf

I think comparing bcrypt with e.g. pbkdf2 is not quite fair for bcrypt since it was an earlier construction and ideas like tweakable number of iterations are actually inspired by bcrypt.

Kris
  • 632
  • 4
  • 8