
Lifetimes of cryptographic hash functions - wwwhizz
http://valerieaurora.org/hash.html
======
kobeya
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).

~~~
kzrdude
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.

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

~~~
jeffdavis
Can you please explain?

~~~
aseipp
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...](http://www.cs.utsa.edu/~wagner/CS4363/SHS/dfips-180-2-comments1.pdf)

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.

~~~
tptacek
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.

------
mtgx
If you're not willing to move to SHA256 "because of performance," you should
at least move to Blake2.

[https://blake2.net/](https://blake2.net/)

There's no excuse for staying with SHA1 at this point.

~~~
thunderbong
From the article -

[3] Google spent 6500 CPU years and 110 GPU years to convince everyone we need
to stop using SHA-1 for security critical applications

~~~
ben_w
And the next fifteen years of Moore's Law will take that down to, what, 1 GPU
month even without further algorithmic improvements? Which are anticipated?

I _still_ see things that use 2-digit years, twenty years after the last
millennium bug should have been fixed.

~~~
username223
"Next fifteen years of Moore's Law?" The recent failure of Intel's "tick-tock"
alternation of process shrinkage and new architecture suggests that however
performance improves in the next 15 years, projecting the last 15 years'
Moore's Law forward is a bad idea. For crypto stuff, I'd think about how
quantum computing may advance by the 2030s.

------
nayuki
What is the status of the Whirlpool hash function? Can it be added to the
color table?

------
Kametrixom
For anyone needing to decide what hash function to use, I recommend to have a
look at multihash:
[https://github.com/multiformats/multihash](https://github.com/multiformats/multihash)

------
bjornsing
> Non-expert ("slashdotter") reaction:

> Explain why a simple collision attack is still useless, it's really the
> second pre-image attack that counts

Why is this the "non-expert reaction?" It's correct, right?

And why go to the trouble of making a timeline with "Broken" and "Collision
found" without a "Second pre-image found"?

I'm genuinely puzzled (and have asked it here on HN before [1]), but I
unfortunately suspect that an honest answer lies somewhere along these lines:
"Second pre-images are a _hell of lot_ more difficult to find than collisions,
so if we waited around for a second pre-image to be found we'd never get to
dance around like headless chickens and talk about really scary shit (which
typically requires a second pre-image) as 'now practical'. That would make the
whole field a lot less sexy, and cut into our 'expert' consulting fees..."

1\.
[https://news.ycombinator.com/item?id=13729492](https://news.ycombinator.com/item?id=13729492)

EDIT: I'm of course not advocating staying with SHA-1. There's absolutely no
good reason to. Even years ago when I was last involved in choosing a
cryptographic hash function (even truncated) SHA-256 was obviously a much
better choice.

~~~
stestagg
I had a similar thought, but actually prefer this way.

People who understand things well enough will know what first collision means,
so can moderate their response.

Others who are less familiar with the ridiculous levels of subtlety around
this sort of thing are better off being given the simple message that sha1 is
now legacy in all cases. Helps to avoid mistakes.

~~~
bjornsing
Simple "truths" are sometimes useful. I can see that.

I'm more surprised though at the resentful attitude towards the actual truth
(in the non-alternative sense): collisions are useless in many cases and the
necessary second pre-image is _much_ more difficult to find.

At least in a forum like HN I'd expect intellectual honesty to prevail.

EDIT: Removed the incorrect example out of pure shame! :P

~~~
detaro
/u/pvg linked below how the ability to generate collisions for MD5 was used to
obtain a fake CA certificate. It's not obvious to me that this would not work
with SHA-1 certificates, and that no other important things we use have
similar weaknesses. (Neither do I know for sure that it would work, but
"collisions are useless" seems like a dangerous simplification in the other
direction. I suspect for many, simply replacing SHA-1 with something deemed
better is easier than thoroughly evaluating the risks involved with not doing
so)

~~~
bjornsing
Now we're getting somewhere in terms of intellectual discussion! :)

I of course agree we should replace SHA-1. But I still think a more
intellectually honest discussion is meaningful. For example, after reading the
link you referred to I'm rather convinced that X.509 is pretty seriously
flawed, and could easily be redesigned to be collision resistant. Why not talk
about that? Why not do it?

~~~
mook
As I understand it, CAs have mitigated the collision attacks by forcing a
random serial number they generate into the certificates. Since that's part of
the hash, collision attacks are no longer practical.

Doing x509 still means having to parse ASN.1 though, and nobody seems to
actually like it.

