Everything you need to know about hash length extension attacks (2012) | Hacker News Reader

Everything you need to know about hash length extension attacks (2012)

skullsecurity.org

58 pointslaurent12345617 comments

A nice tool to play with and to make ppl see how easily home-grown crypto can be broken and why those simple hash(secret || data) constructions are not a replacement for a true HMAC implementation.

Note to self: Again, never ever implement your own crypto. Ever.

I can easily imagine someone thinking that "crypto" covers the choice of hash function, but not the prepend-secret-and-hash construction.

(I'm actually not sure how to quantify what is and isn't crypto, in a way that's easy for a beginner to understand.)

Agree.

Well, maybe stating, that RNGs, hash functions (and XOR ;) are just building blocks and tools to build true functionality out of them, would help. I see it quite similar to statistics. Yes I do know and understand mathematical operations, "numbers" and some statistical operations like average, median and maybe even variance but no way I'm capable to setup a proper statistical trial or analysis.

I tend to fall back to: describing what I'd like to achieve with what kind of properties of the result and let ppl really knowledgeable on the topic find the correct keywords, tools and in the end algorithms.

But boy is it tempting to just mash some hash functions together based on some actually quite naive understanding of their properties ;)

I think I know: only use as directed.

Only use a crypto component for the exact purpose that is stated on the tin. Hash function turns lengthy text into a short unique digest. That's the only thing you can use it for. If you try to use it for any other purpose, you will likely screw it up.

Sure, but you need to then do something with that digest. Store it, compare it against other digests, etc. Whether or not those actions constitute "crypto" is hard to determine.

For example, git uses SHA-1 digests as unique identifiers for commits. Isn't that extending hash functions from unpredictable digest to identity? What happens when someone finally finds a SHA-1 collision? When Linus made that choice, was he breaking the rule about writing your own crypto?

He was inventing his own crypto. The point is not to avoid design decisions that reinvent crypto, the point is to recognize that's what you're trying to do and seek expert help to guide your hand.

I don't imagine many developers see hash(secret||data) as a replacement from HMAC. I made that mistake once, but I had not yet heard of HMAC at the time.

Yup, that's exactly the point! Quite some developers are re-inventing this kind of things without knowing how their solutions are lacking. It's tempting and fun and in the end in case of crypto insecure.

I thought HashPump could be used for hash length extension attacks.

https://github.com/bwall/HashPump

It's a nice post nevertheless and another reason to use HMAC instead of custom MAC (nota bene: SHA-3 is not vulnerable to this attack).

Could you clarify please: is SHA-3 known to not be vulnerable to this attack, or merely not known to be vulnerable to this attack?

Courtesy of tptacek, https://news.ycombinator.com/item?id=5776044

"Most are vulnerable to length extension attacks. SHA3 (Ketchup) is not vulnerable to length extension attacks, because resistance to length extension was a design criteria for the SHA3 contest."

SHA1 is vulnerable because the entire internal state of the hash function is used as the output. This allows you to 'keep going' and extend what was hashed.

SHA-3 is not vulnerable because it only uses a subset of the internal state as the output (256 output vs 1600 internal). You can't keep going because you're missing the necessary state.

Do I get this right: this attack renders suffix-salted passwords public?

Where did you get that from? You can only extend the hash with this, and get a valid hash for "original data" || "something".

No.

I don't understand the following: Why doesn't the server change the length encoded inside the hash when getting a longer string?

There's no length encoded inside the hash, where did you see that? Adding the length in the total hash would probably mitigate this attack, although I'm not sure it would defeat it.

Reply on news.ycombinator.com