IMHO GNU C Library should include support for Blowfish crypt(3) coding. It is
now available as a patch from http://www.openwall.com/crypt/. Currently three
major free *BSD variants offer support for it. It seems to be much better than
than MD5 because of its scalability.
The tiny glibc patch currently included in the crypt_blowfish package might not
be suitable for inclusion - in particular, it assumes that the optional x86
assembly file is misplaced for the sake of simplicity in the current
installation instructions for [advanced] end-users.
If this stuff would be accepted in general only needing a proper patch, I'd be
happy to re-work the patch to make it suitable for inclusion. So please let me
I'm not going to add Blowfish support since this is not solving the problem (see
http://people.redhat.com/drepper/sha-crypt.html). But I did add a new, safer,
not based on MD5 method to cvs.
(In reply to comment #2)
> I'm not going to add Blowfish support since this is not solving the problem
The paper gives good reasons to implement sha-based crypt scheme, no doubt. But
IMHO this does not have to mean glibc cannot support bcrypt(), does it? If you
look at the pages in my first not you will find that *BSD C libraries implement
even more schemes e.g. NT-hash. More algorithms make system more interoperable.
Alexander offered a proper patch to integrate it so there wouldn't be too much
work for you.
Last and least. Forgive me my conspiracy theories but if a government agency
tells me: "use this encryption", I can hear: "we assure you, no one else but us
can break it" ;-)
(In reply to comment #3)
> IMHO this does not have to mean glibc cannot support bcrypt(), does it?
Yes, it does. I'm not carrying around code unnecessarily. And diversity is bad
since this means you run into trouble in heterogeneous environments.
*** Bug 13286 has been marked as a duplicate of this bug. ***
"Basically, Ulrich only wanted to solve a particular problem, namely building upon NIST-approved crypto, and so he introduced SHA-crypt, thereby solving the problem. bcrypt is unrelated to that problem, so it didn't get in, and its OpenBSD origin didn't help either.
Now that Ulrich is no longer involved, things may be different."
Someone new has just followed this "bug", so I felt we should post an update: bcrypt support is currently provided via libxcrypt, which major Linux distros currently use instead of glibc's libcrypt. This reduced the need to have bcrypt in glibc. Further, libxcrypt supports and several major distros now use yescrypt by default, which is in most ways superior to bcrypt (except for its complexity).