[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [patches] crypt_blowfish patch for eglibc
- To: Paul DeBruicker <pdebruic@xxxxxxxxx>
- Subject: Re: [patches] crypt_blowfish patch for eglibc
- From: "Joseph S. Myers" <joseph@xxxxxxxxxxxxxxxx>
- Date: Fri, 29 Apr 2011 23:13:31 +0000 (UTC)
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.
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.
--
Joseph S. Myers
joseph@xxxxxxxxxxxxxxxx