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 > > problem if someone does lots of requests with wrong passwords. > > Therefore I think choosing an algorithm that does not scale well > > on more specialized hardware is good. > > > > Both bcrypt and scrypt can be adjusted in how much CPU time to > > use. scrypt can also be adjusted in how much RAM it uses. bcrypt > > uses a 128bit salt, AFAICS scrypt can use arbitrary salt > > lengths. > > > > Bcrypt has seen a lot more review than scrypt, therefore I am > > somewhat in favor of bcrypt. Crypt_blowfish [6] is an > > implementation with a very liberal license that we could use. > > Scrypt has a 2-clause BSD license which would also be OK. > > > > Opinions? > > We already have integration points to openssl, why add yet another > dependency? Seems foolish.
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.
