apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Laurie <...@links.org>
Subject Re: Choosing a stronger password hash algorithm
Date Mon, 02 Jul 2012 19:15:49 GMT
FWIW, I am not super-keen on this particular move. Whilst bcrypt is
certainly an improvement, I am wary of relying on Blowfish - it is not
a mainstream cipher and is not subject to the kind of scrutiny that,
say, AES or SHA-2/3 are.

If we are going to change, then we should change to a mechanism that
is subject to ongoing cryptanalysis.

On Mon, Jul 2, 2012 at 8:02 PM, Stefan Fritsch <sf@sfritsch.de> wrote:
> 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
> http://people.apache.org/~sf/apr_bcrypt_password_support.diff
> diffstat:
>  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
> i386).
> 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.
> Cheers,
> Stefan

View raw message