Hacker News Reader

Hacker News

Comment by rorrr2 | Hacker News Reader

Full thread

rorrr2

It's missing the most important ones: Scrypt, PBKDF2, Bcrypt.

https://en.wikipedia.org/wiki/Scrypt

https://en.wikipedia.org/wiki/Bcrypt

https://en.wikipedia.org/wiki/PBKDF2

Scrypt being an absolute nightmare to bruteforce, even for short passwords.

http://i.stack.imgur.com/sOMvu.png

View on HN

These aren't cryptographic hash functions exactly, though, at least not in the sense that a cryptographer would think. I mean, they will fit just about any definition of a cryptographic hash function you can think of, but really it's not that useful to label them as such. Instead, they're usually called key derivation functions.

On top of that, even if we were to include these in a hash function list, they're decidedly not the most important ones. Most important for password storage and other key derivation, perhaps, but the applications of hash functions are far more general. The preimage resistance of scrypt is reliant on SHA256, for instance.

Scrypt is being used by a few altcoins (litecoin for one), that's what makes it interesting for some people.

Cryptographic hash functions must be efficient to compute. Those examples (scrypt, bcrypt, etc) were designed to be difficult to compute. Those are password hash functions, not cryptogrpahic hash functions. Two totally different things with different purposes.

Well, in complexity theory (which theoretical cryptography uses heavily), an efficiently computable function is one that has a polynomial-time algorithm to compute it.

I mean, wouldn't you say that scrypt is efficient to compute? For instance, is 5 seconds not a relatively quick function evaluation? Compare that to super-polynomial-time attacks, some of which wouldn't succeed before our Sun burned out and Earth died. And if you ramp up the security parameters to an insane degree, the user can no longer compute the function themselves. That's the reason for the "efficient to compute" clause in most definitions.

So, while you're right that the fact that KDFs are designed to be much slower than hashes is what really separates them, that doesn't disqualify KDFs from (technically) being cryptographic hash functions. At least, not if you view the definition in a theoretical sense, which is the appropriate way to do so. Still, I agree with your premise; in a practical sense, KDFs shouldn't feel like they are cryptographic hashes, since their purpose is markedly different.

Can you explain why a 40 char text is 1000 times easier to crack than a 10 char password according to the graphic? Is it assumed you don't use any numbers/symbols and the attacker knows your dictionary?

I think "text" is english + whitespace + punctuation only, whereas "password" is any kind of character.

I didn't create that image, so I'm not 100% sure.

You're correct. See the original scrypt paper by Percival [1], halfway down page 13, for a description of the categories. The table itself is at the top of page 14.

[1] https://www.tarsnap.com/scrypt/scrypt.pdf

The "40 char text" is based on NIST guidelines for estimating the entropy in English text -- i.e., dictionary words which make grammatical sense together. The "10 char password" is for 10 random printable ASCII characters.

Reply on news.ycombinator.com