Hacker News Reader

Comment by tptacek | Hacker News Reader

You are going to have a hard time finding a professional cryptographer who will look at scrypt and say that it's risky. These are KDFs, not message authentication codes; they aren't risky constructions.

If you have no other choice but to iterate SHA1 many thousands of times, that's still better than what most apps do, and in the grand scheme of things almost "ok".

scrypt is fine. If you have a library that supports it, go ahead and use it.

View on HN

> If you have no other choice but to iterate SHA1 many thousands of times, that's still better than what most apps do, and in the grand scheme of things almost "ok".

While I won't recommend people simply iterating a hash many times, I also won't slap people down for it anymore. In the grand scheme of things, there are a billion more likely routes of attack than someone breaking your 20000-rounds-of-SHA1 hashes.

Out of curiosity, what do you recommend people use?

If being able to do things with off-the-shelf tools is important, I'd recommend PBKDF2. It can be implemented in a couple dozen lines of code over one of the SHA2 functions, as opposed to Bcrypt which is a completely novel hash function that isn't in most languages' standard libraries.

Much as I like bcrypt/scrypt, I generally just recommend PBKDF2 with a large number of rounds. It's not perfect, but it's more than good enough.

This is true. In particular, a KDF is in no danger from preimage or collision attacks, which are generally the types that show up.

Reply on news.ycombinator.com