Re: [patches] crypt_blowfish patch for eglibc

["Joseph S. Myers" <joseph@xxxxxxxxxxxxxxxx>]

On Fri, 29 Apr 2011, Paul DeBruicker wrote:

> > 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.

It appears the code is adding new (undocumented) interfaces crypt_rn, 
crypt_gensalt, crypt_gensalt_rn, crypt_ra, crypt_gensalt_ra which is why 
it needs symbol versions for them.  The threshold for adding new exported 
symbols in certainly greater than for simply adding a new algorithm (and 
certainly requires documentation in the glibc manual for the new 
interfaces).

I don't think adding new algorithms ought to require glibc changes; it 
ought to be possible to load them dynamically, just like gconv and NSS 
modules.  Such dynamic loading could be a useful feature.

There is a general principle that glibc is not meant to contain C 
interfaces just because they are useful; it's meant to contain the basic C 
and POSIX interfaces, interfaces to Linux system calls, and other 
interfaces that are so closely related to the above that glibc is the only 
natural place for them (for example, hooks into the malloc code).  In many 
cases, a separately maintained library is a better place for slightly more 
specialized interfaces that are not in ISO C or POSIX.  Even some of the 
executable tools provided by glibc might better be distributed and built 
separately rather than at the same time as libc itself is built (still 
associated with the glibc project), and it would be logical for the locale 
data, for example, to be a completely independent project rather than part 
of glibc.

(The next merge from FSF glibc to EGLIBC will bring in the changes that 
prevent the old sunrpc code being used by new programs, deprecating it in 
favor of the separately maintained TIRPC library.  This is an example of 
these principles in action: code for niche interests is best maintained by 
people with relevant expertise, in separate projects.)

So when you are adding new cryptographic interfaces such as this patch 
does, one must ask whether glibc is really the right place for additional 
cryptography support.  Fedora recently looked at reducing the number of 
different cryptographic libraries in use in that distribution, for a range 
of reasons, and settled on NSS as the preferred library - see 
<http://fedoraproject.org/wiki/FedoraCryptoConsolidation>.  This certainly 
doesn't guarantee that other GNU/Linux distributions will follow, but it 
does suggest you might want to consider NSS as a cryptographic library for 
your application - and if other distributions do follow, libcrypt could 
end up mainly as legacy code, given how limited its purpose is compared to 
the complexity of modern cryptography.

> 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

So do the SHA-256 and SHA-512 based encryption algorithms.  Comparisons 
against plain SHA-256 or SHA-512 hashing (single-round) are completely 
irrelevant here since that is not what is implemented in glibc.

-- 
Joseph S. Myers
joseph@xxxxxxxxxxxxxxxx