3 ms·
Re: Password Hashing Competition: maybe, but I think there are some subtleties you're glossing over that are worth pointing out. We have more confidence in scr
by lvh 9y ago
Re: Password Hashing Competition: maybe, but I think there are some subtleties you're glossing over that are worth pointing out.
We have more confidence in scrypt because of the analyses PHC fostered. We (well, everyone not named 'cperciva perhaps :)) didn't really have a proper independent framework for analyzing hardness statements. So yes, scrypt is fine, but we say that with a lot more confidence because of PHC research.
PHC also matters for reasons similar to NIST password recommendations. Now if your questionnaire balks that I'm not using $x, I can say "go away, we are following $blessed_practice" as opposed to "we use this thing that this one dude wrote but it's the best we promise". It was the best, but dumb questionnaires still matter even if they're dumb. (Clearly PHC does not carry the same weight as NIST, but at least there's some semblance of authority and academic consensus you can point to.)
I agree that it's regrettable that the outcome of the PHC wasn't just "scrypt is fine, use it". Though a deployment model that isn't "go steal this .c and .h from this one tarball of a different application on this one site" is nice, and now there's significant impetus to make that happen.
> ... and a whole lot of new mechanism being proposed to find reasons to deploy it.
I don't understand what you mean. Can you elaborate?
Just so no-one misconstrues any of my points: I emphatically agree that the vast majority of people should just use what their framework gives them because it's probably totally fine.
- tptacek 9y agoBy "new mechanism" I mean things like server-relief handshakes, or reasons to build protocols around KDFs instead of just hashing passwords.