Regulators, Password Hashing & Crypto considered as a Branding Exercise: #bcrypt #security /cc @schneierblog @glynwintle

Pardon the rambling, mildly-edited nature of this, but: earlier this year, Whit Diffie mailed me and asked:

What is your view of BCrypt and how does it relate to the algorithm you did for Sun? I can’t recall whether yours was earlier or later, so I don’t know whether to ask why you didn’t use BCrypt.

…and I replied, cc’ing Ulrich Drepper:

Hi Whit, [cc: and Hi Ulrich]

On 15 Jun 2012, at 05:19, Whitfield Diffie wrote:

What is your view of BCrypt

  • Niels Provos
  • Good guy
  • Blowfish based
  • Limited to [72 character] passwords but that’s OK/ish.
  • Good (i.e.: memory hungry) expansion phase means it’s unlikely to be put on a GPU any time real soon.**
  • Strong branding – relevant function name with few ambiguous clashes – unlike SHA256-FOO-PBKDF2-BAR branding of some password-hashing-friendly algorithms that confuse web developers who only hear SHA-256 and use that instead

If you want to take a message to your next crypto conference, please tell them that they need to start branding their algorithms because the ignorant code monkeys get confused easily.

For all of of the above reasons – especially the latter, no joke – I recommend bcrypt() to the universe for almost ALL applications of password hashing.


and how does it relate to the algorithm you did for Sun?

[It was an] Elegant, amusing hack which addresses some, perhaps most of the issues that bcrypt() does – but which suffers from:

  • being from Oracle now
  • being based on MD5 which though quite legitimate in these circumstances has had its reputation trashed amongst the semi-literate security geeks
  • having the name SunMD5 which contains the name MD5 which – previous point aside – means people think they can use any old MD5 library and get most of the benefit for cheap; but the reputation-trashing has also done for that

Had we called it hiccough or something bizarre, it might have taken off and survived to this day.

I can’t recall whether yours was earlier or later, so I don’t know whether to ask why you didn’t use BCrypt.

Because the point was not to come up with a new algorithm, that was just a sideline to generate some new ideas and to show off the benefits of the new Pluggable Crypt API that Casper, Darren and I designed; and it evidently worked:

The commonly used MD5 based scheme has become easier to attack as computer power has increased. Although the Blowfish-based system has the option of adding rounds and thus remain a challenging password algorithm, it does not use a NIST-approved algorithm. In light of these facts, Ulrich Drepper of Red Hat led an effort to create a scheme based on the SHA-2 (SHA-256 and SHA-512) hash functions. The printable form of these hashes starts with $5$ or $6$ depending on which SHA variant is used. Its design is similar to the MD5-based crypt, with a few notable differences:

  • It avoids adding constant data in a few steps.
  • The MD5 algorithm would repeatedly add the first letter of the password; this step was changed significantly.
  • Inspired by Sun’s crypt() implementation, functionality to specify the number of rounds the main loop in the algorithm performs was added. The specification and sample code have been released into the public domain.

…but RedHat made the cardinal mistake of calling the algorithm SHA2 which means that nobody is going to use it because normal people can’t distinguish between that and the family of other cryptographic hash functions.

If they had named it bongweasel or something the community would be all over it now.

Perhaps it’s time to do a Pidgin-like rebranding exercise on it?

…Drepper – being the author of the algo above – replied:

You’re missing the reasons for the new implementation and also why anything like bcrypt is completely unusable: regulators.

The regulators in certain industries only “know” that

  1. MD5 == bad
  2. SHA-2 == tested and not broken
  3. any other crypto algo == [extra] work for them

This is why SHA-2 was used and why having SHA in the name is necessary.

I don’t say that these are good reasons. But you deal with the government and InfoSec departments…

Drepper has credentials with financial services; however I responded:

I get that; however I think it’s easy to say “PseudoBrandableName, which is based on the SHA-2 algorithm” – compare: “bcrypt() which is based on Blowfish” – this is not meant as a criticism of you/RedHat but I honestly believe that the wrong naming decision was made in terms of encouraging adoption.

In conversations with non-cryppies (i.e.: most devs) who asked me for advice on this I several times had to go chasing after them and say “No, no! not SHA256!“, when I heard them repeating [the error] to their friends; the poor kids hear SHA-2 and their brain fills in the (incorrect) rest, and they pull in a SHA-256 library and roll their own hashes… which is disastrous.

And they tell their fellow devs, which is worse.

So if you don’t care to consider changing the naming that’s your decision, and I can see why. That’s fine. I wish I had named SunMD5 something better, but I did not understand this back then.

But I care less about mildly confusing a supposedly-ignorant regulator than I do about fixing the certainly-ignorant free market and so will be doing what most of the UK pentester geeks I know are also doing, which is recommending Bcrypt() until such time as something better-and-unambiguous comes along; here in the UK the government agencies are adopting open-source tools to replace proprietary solutions, and because of this movement they are getting BCrypt because that’s the best we can provide them with in terms of (say) widespread support in WordPress/Drupal/Alfresco/Java/PHP.

UK regulatory approval of Bcrypt() will follow in the wake of that.

So that’s what I’m thinking: we need better branding. Bcrypt() and Scrypt() is on the fringes of having a good name and having bcrypt() confused with its parental Blowfish is only acceptable because it requires particularly tenacious developer ignorance to deploy a symmetric encryption algorithm as a hashing function* without realising ones’ mistake.

And I still think “bongweasel” would be an excellent hashing algorithm name.


* Yes, I do know the history of DES-based Morris crypt() and realise the irony of this sentence. But the point stands.

** Bcrypt footnote from Glyn Wintle:

Just for clarity, Blowfish encryption itself is implementable faster on GPUs but only with the same key

The key setup is where the problem lies, maintain separate large S-boxs per key causes all sorts of problems.

Also for referance using john assuming that its set to 1024 iterations ($2a$10 prefix) the kind of numbers you get on a cpu are a few thousand c/s in other words in the real world at the momment with non stupid passwords, this is a very good password hash. Now as you and I know the definition of a stupid password is where the fun starts …

John currently has a GPU version, blowfish-opencl that runs on a 7970, its half the speed of the cpu code at the momment. The fact you can dial up the difficulty of bcrypt is the long term win. 🙂

On a diffrent note, Sha512 (insert correct letters here to make Alec happy) is very doable on a GPU, the biggest issue is that you have to do 64 bit maths so this slow things down a little bit because gpus are optimised for 32 bit math, so you end up haveing to do two 32 bit operations.

9 Replies to “Regulators, Password Hashing & Crypto considered as a Branding Exercise: #bcrypt #security /cc @schneierblog @glynwintle”

  1. @glynwintle writes:

    @AlecMuffett since those emails, atom added bcrypt to hashcat-plus – it runs at 4020 c/s on a 7970 graphics card.

  2. One thing I have learned is that no matter how many times you tell coders NOT to roll their own… they always see it as a challenge that they can and will do so… with the usual disastrous results.

    The more I have seen bcrypt pushed the more I see web developers going for “md5(md5(salt). md5(password)+magic_sauce(password+salt)).” {heck I would be happy to see them use a salt or magic_sauce()}

  3. Reading all this.. and still confused about the SHA2 vs SHA256/512 malarky..
    Guess I’ll resign to being a confused dev and just use Bcrypt (until its obsoleted anyway)

  4. Hi Alec,

    Assuming that I read attribution right, you say “I recommend bcrypt() to the universe for almost ALL applications of password hashing.” Can you say why you push for bcrypt over scrypt or PBKDF2?

  5. Hi Adam,

    Bunch of soft reasons: bcrypt() is more widely deployed than scrypt(), there are more implementations (albeit under stupid names sometimes) and it’s fairly easy for J.Random Programmer to pick up a one-stop library with code examples.

    Scrypt, not so much. Also, empirical hearsay from people I trust does suggest that Bcrypt is more of a pain on GPUs than Scrypt().

    PBKDF2 is yet another fucking acronym and essentially a wrapper around some other hash, and why would I want to point J.Random Programmer at something which would leave him or her with open questions to answer?

    So: Bcrypt = popular, and few brains required.

  6. ps: rename scrypt() as BongWeasel (or whatever) and provide reference code for every language under the sun, in native Perl/C/PGP etc – as well as – hooks to C versions, under popular FOSS licenses, and I might consider plugging it.

Leave a Reply

Your email address will not be published. Required fields are marked *