Bug 2100 - blowfish crypt support
Summary: blowfish crypt support
Alias: None
Product: glibc
Classification: Unclassified
Component: crypt (show other bugs)
Version: unspecified
: P2 enhancement
Target Milestone: ---
Assignee: Ulrich Drepper
: 13286 (view as bug list)
Depends on:
Reported: 2006-01-01 16:49 UTC by Łukasz Stelmach
Modified: 2023-06-23 11:56 UTC (History)
8 users (show)

See Also:
Last reconfirmed:
fweimer: security-


Note You need to log in before you can comment on or make changes to this bug.
Description Łukasz Stelmach 2006-01-01 16:49:12 UTC
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.

Comment 1 Alexander Peslyak 2006-05-28 17:51:21 UTC
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
Comment 2 Ulrich Drepper 2007-09-19 22:38:27 UTC
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.
Comment 3 Łukasz Stelmach 2007-09-26 07:57:48 UTC
(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" ;-)

Comment 4 Ulrich Drepper 2007-09-26 18:19:31 UTC
(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.
Comment 5 Dmitry V. Levin 2017-06-01 10:46:51 UTC
*** Bug 13286 has been marked as a duplicate of this bug. ***
Comment 6 Dmitry V. Levin 2017-06-01 10:49:36 UTC
"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."
Comment 7 Alexander Peslyak 2023-06-23 11:56:15 UTC
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).