View Bug Activity | Format For Printing
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.