Re: Choosing a stronger password hash algorithm

2012-07-02 Thread Stefan Fritsch
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

Re: Choosing a stronger password hash algorithm

2012-07-02 Thread Ben Laurie
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

Re: Choosing a stronger password hash algorithm

2012-07-02 Thread Stefan Fritsch
On Monday 02 July 2012, Ben Laurie wrote: 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

Re: Choosing a stronger password hash algorithm

2012-07-02 Thread Ben Laurie
On Mon, Jul 2, 2012 at 8:46 PM, Stefan Fritsch s...@sfritsch.de wrote: On Monday 02 July 2012, Ben Laurie wrote: 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

Re: Choosing a stronger password hash algorithm

2012-07-01 Thread William A. Rowe Jr.
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

Re: Choosing a stronger password hash algorithm

2012-06-29 Thread Stefan Fritsch
On Tuesday 26 June 2012, William A. Rowe Jr. wrote: On 6/24/2012 3:34 AM, Stefan Fritsch wrote: On Sunday 24 June 2012, Graham Leggett wrote: Ideally, like we have a generic synchronous encryption API, we should have a generic hash API too, so that the user can use whatever hash that the

Re: Choosing a stronger password hash algorithm

2012-06-25 Thread William A. Rowe Jr.
On 6/24/2012 3:34 AM, Stefan Fritsch wrote: On Sunday 24 June 2012, Graham Leggett wrote: Ideally, like we have a generic synchronous encryption API, we should have a generic hash API too, so that the user can use whatever hash that the underlying toolkit provides. I rather like the fact

Re: Choosing a stronger password hash algorithm

2012-06-24 Thread Stefan Fritsch
On Sunday 24 June 2012, Graham Leggett wrote: On 24 Jun 2012, at 12:01 AM, Stefan Fritsch wrote: Openssl is not required, neither for apr nor for httpd. I propose to import either crypt_blowfish or scrypt into apr, just like apr contains some foreign sha1 and md5 code. This way we would

Re: Choosing a stronger password hash algorithm

2012-06-23 Thread Stefan Fritsch
On Saturday 23 June 2012, William A. Rowe Jr. wrote: On 6/23/2012 3:42 PM, Stefan Fritsch wrote: bcrypt [1] and scrypt [2] seem to be much more difficult to port to hardware or GPUs than sha256/512_crypt [3-5]. We can't make the operation too expensive on normal CPUs or we create a DoS

Re: Choosing a stronger password hash algorithm

2012-06-23 Thread Graham Leggett
On 24 Jun 2012, at 12:01 AM, Stefan Fritsch wrote: Openssl is not required, neither for apr nor for httpd. I propose to import either crypt_blowfish or scrypt into apr, just like apr contains some foreign sha1 and md5 code. This way we would not get an additional external dependency.