Re: Choosing a stronger password hash algorithm
Ben Laurie <ben <at> links.org>
2012-07-02 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 <at> 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
> 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
>> 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
> Yes. That's why I was sceptical about using apr_crypto for this task,
> too. After all, apr_crypto is still optional.