[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [patches] crypt_blowfish patch for eglibc

Thanks for the reply. Since I wrote the earlier email I learned about libxcrypt which I think may address my needs for having a portable C implementation of the bcrypt password hashing scheme in Linux. I do respond to your questions/concerns below.
I am a Smalltalk programmer and do not know much about C or its libraries. I am happy to have any suggestions or changes or improvements made. 



On 04/29/2011 07:13 PM, Joseph S. Myers wrote:

On Fri, 29 Apr 2011, Paul DeBruicker wrote:


*** ../eglibc-2.12.1/Versions.def	2010-01-26 06:27:38.000000000 -0500
--- Versions.def	2011-04-28 11:26:15.614637002 -0400
***************
*** 39,44 ****
--- 39,46 ----
   }
   libcrypt {
     GLIBC_2.0
+   GLIBC_2.2.1
+   GLIBC_2.2.2
   }


You can't add symbol versions to existing libraries like that.  If you
need a new symbol version for something in EGLIBC (or generally if you
wish to export an EGLIBC-specific symbol), it needs to be in an option
group that is disabled by default and the symbol version needs to be in
the form EGLIBC_* with a name reflecting the option group involved.
OK. I do not know the reasoning behind the change to the Versions.def file or whether it is necessary or not. It was in the diff I linked to in my previous email so I left it in when updating the diff to "work" with eglibc 2.12.1 and crypt_blowfish. 



Could you please explain (with appropriate references) what advantages
this algorithm has over the SHA-256 and SHA-512 based algorithms added in
glibc 2.7?  In the absence of clear cryptographic justification, adding
the choice of more algorithms isn't generally a good idea, because of the
risk of vulnerabilities in the new algorithms or in the way selection is
made between the algorithms.  Is this about compatibility with existing
passwords hashed using the blowfish scheme?  Controlling the set of
supported algorithms with option groups does seem to make sense, if not
already implemented.
The paper written by the algorithm's authors [1] describes the reasoning more fully but the gist of it is this. In bcrypt the key set up phase has a configurable number of rounds of encryption. As computers get faster this number of rounds can be increased to make brute-force & rainbow table attacks increasingly costly. Instead of developing, proving, and adding e.g. SHA-1024 in the future you can just increase the work factor of this algorithm. It is designed to be slow and to obscure plain-text passwords. Not be a general purpose hashing algorithm like SHA-256 and SHA-512. The site and paper in [2] has some data about how slow it is relative to other schemes. The first answer to this Stack Overflow thread also provides a good overview of the differences between SHA-512 and bcrypt [3].
This is not about compatibility with existing passwords hashed using this scheme. That may be an ancillary benefit or cost. I don't know.
I personally wanted it available in libc because my Smalltalk implementation is too slow to make use of the algorithm in a reasonable amount of time. I'm probably doing-it-wrong. But I also think it should be in libc because, as shown in the links on [2] there are currently Python, Ruby, PHP, LISP, and Erlang libraries that have each adapted C code and made interfaces to either the openwall.com or openbsd [4] C versions. It is also mentioned in the crypt(3) manpage, but is not a standard feature in Linux currently. I think its only in Suse and Owl linux. Suse has a crypt_blowfish diff against libc in their glibc source rpm [5]. By my count that's at least 7 C implementations for linux with different interfaces (Ruby, Erlang, Lisp, Python, openwall.com, suse, libxcrypt)
Arguing against my position is [6] and [7]. And I am not storing sensitive data that is under threat so could certainly use one of the already implemented hashing methods or interface to an existing implementation.
Really at this point in time I think using the libxcrypt library will be just fine for my needs, but wanted to get you this information in the event you had other ideas. 


Thanks again

Paul DeBruicker


[1] http://www.usenix.org/events/usenix99/provos.html

[2] http://codahale.com/how-to-safely-store-a-password/
    http://www.usenix.org/publications/login/2004-06/pdfs/alexander.pdf

[3] http://stackoverflow.com/questions/1561174/sha512-vs-blowfish-and-bcrypt

[4] http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc/crypt/
[5] https://build.opensuse.org/package/view_file?file=crypt_blowfish-1.0-suse.diff&package=glibc&project=openSUSE%3A11.4 

[6] http://www.akkadia.org/drepper/sha-crypt.html

[7] https://bugzilla.redhat.com/show_bug.cgi?id=173002