Hacker News Reader

Comment by kobeya | Hacker News Reader

The SHA-256 "weakness" is a bit disingenuous. As far as I'm aware in the 10 years since that paper was published the "weakness" hasn't been extended _at all_. The main reason for the SHA3 competition was because we were all concerned at the time that SHA2 would be broken and there'd be nothing to replace it with. However as it happens, SHA2 has remained rock solid, so the outcome of SHA3 was to pick something (Keccak) maximally different from SHA2, since in the intervening years cryptographic diversity became more desired than actual replacement. Both SHA2 and SHA3 are fit for use in production systems -- I would personally pick SHA2 unless I had some specific reason to benefit from SHA3 (e.g. incremental hashing modes that the sponge construction makes possible).

View on HN

The problem here is that the green cells mean "considered strong" and the yellow cells mean... something else. But among practitioners, SHA-2 is still very much considered strong.

I'm also not clear on what the chart claims is going on with RIPEMD-160.

Probably 80bit collision resistance would be my guess. But that's not a concern for applications that require preimages to attack (e.g. Bitcoin 1... keys).

It looks like it's important to switch to a variant of SHA-2 that is truncated (like SHA-384 or SHA-512/256 for example), since they are more robust. No trivial length extension attack since they don't put the whole internal state in the output.

This would be if one cares about how violently you fall if SHA-2 is broken more, but I think you should care.

Or design your protocols to be safe from length extension attacks in the first place.

Some people don't understand crypto. That's where SHA-3 could save them.

FTFY: s/Some/Most/

Can you please explain?

EDIT: I realized you were asking about "design your protocols against length extension", not "what is length extension". Sorry. Ignore this, but I'll leave the response for anyone else who is curious

---

SHA-{1,2} are vulnerable to length extension attacks, because of the way their Merkle-Damgard construction works. Basically, if you have the result HASH(X), you can calculate HASH(X+P), knowing only 'HASH(X)', without knowing 'X' itself. This is problematic because it means you can effectively "extend" some cryptographically hashed data with an arbitrary suffix.

You can immunize SHA-2 in one of two ways to a length extension attack:

- Truncate the hash value. For example, use SHA-512, but truncate the result to 256 bits (this is called "SHA-512/256"). This works because the output of your HASH function which is 256-bits, cannot be reused as the initial starting state for a new round of HASH (e.g. SHA-512 needs a 512-bit starting value, but the output is only 256, so this makes it impossible)

- Although it is not standard SHA-2 anymore, you can use a trick from Neils Ferguson and John Kelsey (from 2001!) to immunize it -- simply XOR a constant into the final block round before running the final compression function. Unfortunately this suggestion was not adopted for SHA-2: http://www.cs.utsa.edu/~wagner/CS4363/SHS/dfips-180-2-commen...

Alternatively just use a modern hash design like BLAKE2, SHA-3, or a number of others -- these avoid the entire problem. I'd suggest just sticking to one of those two.

I object to the notion that SHA-3 and Blake2 are "modern" hash functions and that SHA-2 isn't. SHA-2 remains a first-line hashing recommendation among crypto designers. The Noise protocol framework, for instance, includes it, as does Nacl; the authors of both of these systems had hashes available that didn't have length extension.

If I had to rank those three hash functions, SHA-2 wouldn't be in last place.

E.g. Use an HMAC construction.

That's not how I would put it. Existing protocols that use full-width SHA-2 aren't inherently suspect for doing so, but new designs that use SHA-2 directly might benefit from doing so. It's worth remembering that most uses of SHA-2 in real protocols occur in MACs and PRFs, where length extension either isn't a problem or is addressed specifically.

Another way to look at it is, not needing HMAC is a feature of SHA-3.

In any case: SHA-2 --- in any of its variants --- remains strong. JP Aumasson, one of the Blake2 designers, is fond of saying that SHA-2 will probably never be broken algorithmically.

Using a truncated SHA-512/256 also has the advantage of being considerably faster than SHA-256 on 64-bit CPUs. The performance difference is close to 50%. As such, I see no reason to use SHA-256 for anything[1], you're better off just using SHA-512/256 as the net storage is the same as well (32-bytes).

[1]: Assuming you're running on a 64-bit platform...

For hashing large data, yes. For password derivation schemes or hash trees, no. SHA512 is only faster per byte because the block size is larger. SHA256 has faster rounds.

If you're using SHA-anything for hashing passwords you're doing it wrong.

Industry standards like PBKDF2 use hash functions like SHA internally.

Maybe a dumb question: if sha2 and sha3 are so different, wouldn't it make sense to just use both and XOR the results?

I wouldn't do any such thing without thorough analysis. It very well might have unexpected consequences.

You can concatenate hash functions, so you get at least the best security from both. But the question is: Why would you want to do any such thing? Just choose one of them. Both are safe.

XOR? No. That very likely breaks it entirely. But you could chain the algorithms, which is what Bitcoin does for its standard payment addresses.

SHA-3 is faster in hardware!

Almost nobody has SHA-3 capable hardware though, and "getting it" is a lot of work (either pay money or work on an FPGA I guess). I'd argue SHA-3 being efficient in hardware is almost completely irrelevant for 99% of all users of cryptographic software. For the vast majority of people, I think fast software implementations are way more important -- especially as systems like NFV and SDN come into play at large scale (people want bog-standard x86 boxes for this stuff).

I almost wish SHA-3 had been a dual pick between a fast software hash and a fast hardware hash. As it stands, Keccak being so slow in software is majorly limiting IMO. The more interesting aspect of SHA-3 is the sponge, so you can really turn Keccak into an entire swiss-army knife of crypto tools, if you know what you're doing.

But as it stands, if I have to pick a modern hash, I almost always pick BLAKE2 instead of SHA-3, primarily because I rarely need the sponge design and also because it's dramatically faster in software. Stuff like this is really important on my Cortex-M4...

> I'd argue SHA-3 being efficient in hardware is almost completely irrelevant for 99% of all users of cryptographic software.

I'd argue that for 99% of all users of cryptographic software, the difference in speed between SHA-2 and SHA-3 is irrelevant.

BLAKE2 is a fine hash too :]

SHA2 hardware is faster than SHA3 in software (which is the real comparison for any project made today).

Reply on news.ycombinator.com