apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Fritsch ...@sfritsch.de>
Subject Re: Choosing a stronger password hash algorithm
Date Mon, 02 Jul 2012 19:02:11 GMT
On Sunday 01 July 2012, William A. Rowe Jr. wrote:
> On 6/29/2012 4:23 AM, Stefan Fritsch wrote:
> > Therefore I will go ahead and add bcrypt support to apr-util
> > which will be a big improvement for the 95% of users who don't
> > need FIPS.
> It sounds to me that after we spent a great deal of time to make
> APR largely library agnostic, you are insisting on binding us to a
> specific library.  I would be very hostile to that.

No. As I have mentioned in one of the other mails, I prefer importing 
a suitably licensed version of the source code.

What I currently have is



 build.conf              |    2 
 crypto/apr_md5.c        |  145 -------
 crypto/apr_passwd.c     |  196 ++++++++++
 crypto/crypt_blowfish.c |  902 ++++++++++++++++++++++++++++++++++++++
 crypto/crypt_blowfish.h |   27 +
 include/apr_md5.h       |    5 

> If you are talking about a plugable, client-agnostic approach which
> the user can ignore the details of how apr was built, that would be
> fine.
> Before throwing code at APR, please post a patch, because the group
> might largely be in agreement.  The delta to configure.in and the
> headers is probably sufficient for now.  But if your solution is to
> add more mandatory dependencies or make apr less flexible, it would
> be met with resistance.

No new dependency, no configure.in change. Instead I add two files 
from the crypt_blowfish distribution. I intend to make some benchmarks 
with the assembler version, but it says it was written for Pentium 1, 
so I am not so sure that it will greatly improve performance on 
current processors. If it is actually significantly faster than the 
pure C version, I would add it plus the necessary build logic. That 
would mean one additional file (there is only an assembler version for 

The diff of crypt_blowfish.c versus upstream is one line. So importing 
new versions if there happen to be any upgrades should be easy.

> The user should remain largely oblivious whether the pw crypt used
> lives in bcrypt or openssl or the kernel, and the resulting pw data
> should be always portable between different builds of apr.  This
> was the logic behind the sha1, md5 and other common password
> schemes. The crypt scheme was an exception, one which can be
> resolved even on win32 and hpux with the use of openssl's crypt
> implementation or linking to fcrypt.
> Platform or library binding dependent pw data takes us back to
> 1999.

Yes. That's why I was sceptical about using apr_crypto for this task, 
too. After all, apr_crypto is still optional.


View raw message