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. http://www.freebsd.org/cgi/man.cgi?query=crypt&apropos=0&sektion=3&manpath=FreeBSD+6.0-RELEASE+and+Ports&format=html http://www.openbsd.org/cgi-bin/man.cgi?query=crypt&apropos=0&sektion=3&manpath=OpenBSD+Current&arch=i386&format=html http://netbsd.gw.com/cgi-bin/man-cgi?crypt+3+NetBSD-current
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 know.
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) But > 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). https://github.com/besser82/libxcrypt