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.
