
We have broken SHA-1 in practice - shizcakes
http://shattered.it
======
merricksb
Active discussion:
[https://news.ycombinator.com/item?id=13713480](https://news.ycombinator.com/item?id=13713480)

------
mshenfield
StackOverflow post explaining how Git would handle a SHA-1 collision

[http://stackoverflow.com/questions/9392365/how-would-git-
han...](http://stackoverflow.com/questions/9392365/how-would-git-handle-a-
sha-1-collision-on-a-blob)

~~~
tym0
Yeah, it seems like a non issue for Git.

------
singularity2001
> Here are some numbers that give a sense of how large scale this computation
> was:
    
    
        Nine quintillion (9,223,372,036,854,775,808) SHA1 computations in total
        6,500 years of CPU computation to complete the attack first phase
        110 years of GPU computation to complete the second phase
    
    

So no need to panic or urgently switch, but time to slowly transition

~~~
simias
Ars technica's article is not as optimistic:

> Had the researchers performed their attack on Amazon's Web Services
> platform, it would have cost $560,000 at normal pricing. Had the researchers
> been patient and waited to run their attack during off-peak hours, the same
> collision would have cost $110,000. That's within the $75,000 to $120,000
> range CWI's Stevens projected in late 2015.

Not cheap but definitely achievable by a wealthy individual or corporation.

~~~
gorbachev
How long would the processing have taken?

------
ktta
I removed this comment from here, and posted it here:

[https://news.ycombinator.com/item?id=13713557](https://news.ycombinator.com/item?id=13713557)

~~~
UnoriginalGuy
> SHA-1 is still used in some important software like torrents and git.

Which can be appropriate. Not every use of SHA-1 is security focused, it might
also be combined with a file size and used to check for file consistency.

The same thing happened with MD5 (which is much more broken). People freaked
out because some software was using the "insecure" algorithm while entirely
missing that it was used a file consistency check (in combination with file
size) rather than for security within its own right.

If you're doing security work, you should already know that SHA-1 is
unacceptable. If you aren't doing security work then you MIGHT want to look
into something else but only if there would be a benefit to someone abusing a
SHA-1 collision.

~~~
simias
>Which can be appropriate

I disagree. Obviously if you have a big distributed infrastructure (like git)
then you won't be able to switch within a day, but that's a pretty extreme
example. They _should_ be working on moving away from it though, pandora's box
is open now, it's only going to get easier and cheaper.

There's no benefit until there's a benefit. If you're using a hash it's
probably because you want a compact way to reference a resource, or maybe
simply check it's integrity. If this property no longer holds then it's
basically useless. You can ignore it until somebody decides to forge
collisions in your system in order to corrupt files or DoS it somehow.

Or you use SHA-1 to deduplicate your files, somebody stores two colliding PDFs
and you delete one of them because you think they're dupes.

So I don't think there's any nuance needed here. The word should be "stop
using SHA-1". Otherwise people will keep making excuses not to do it until
something important breaks.

------
Charged_Buffalo
Well, looks like this guy was wrong:
[https://lwn.net/Articles/307281/](https://lwn.net/Articles/307281/)

Copy-pasting for posterity:

    
    
      I've been informed by the git Gods that the chances of a
      SHA1 collision is the same as the Earth being sucked up into 
      the black hole created by the CERN accelerator. If this is 
      indeed true, then there's no need for that extra memcmp.

~~~
not-tsuraru
Well he seems to be talking about a random collision, not an attack. So not
really the same subject.

See the end of his post: "He did show some concern that there might be a way
to crack the algorithm"

------
seycombi
>...That means Git and unknown number of other widely used services that rely
on SHA1 have THREE MONTHS to wean themselves and their users off the insecure
function

[https://arstechnica.com/security/2017/02/at-deaths-door-
for-...](https://arstechnica.com/security/2017/02/at-deaths-door-for-years-
widely-used-sha1-function-is-now-dead/)

~~~
hvidgaard
That is a bit of hyperbole. Just as MD5 is a good hash function, as is SHA1 -
they just are not good cryptographical hash functions. We've known this for
more than a decade, so this is just confimation of what we already knew.

That said, it's relatively straight forward to upgrade Git for instance, but
it will break all external linking to a repository unless they store both new
and old hashes for existing commits. If the hashing function in Git should
have been secure, it should not have been created with SHA1 in the first
place, as it was known to be broke before development even began.

------
mckoss
Computing a collision today costs about $100K from my reading of the paper. So
most uses of SHA1 are protecting documents of far lower value, and would not
be likely attack targets (today).

~~~
baq
if there are any important ssl certs signed with SHA-1, the race has just
started.

------
rpdillon
I can't tell from the various sites that have covered this, but it seems this
is faster brute force attack (much faster), but not a preimage attack. Am I
reading this correctly?

------
djhworld
Can someone explain how they made the two PDFs cause the same hash, I feel
that's the bit that's missing from the explanation

~~~
Daviey
Almost certainly padding the file to match.

------
mtgx
I knew Google "knew something" about SHA-1 being vulnerable to collisions when
it announced the aggressive timeline for deprecating SHA-1 support.

They got a lot of flak for trying to deprecate it "so early". It's nice to see
them proving everyone wrong on this.

------
necessity
> If you use Chrome, you will be automatically protected from insecure TLS/SSL
> certificates, and Firefox has this feature planned for early 2017.

No need to wait. The option to reject SHA-1 certificates on Firefox is
`security.pki.sha1_enforcement_level` with value `1`.

[https://blog.mozilla.org/security/2016/01/06/man-in-the-
midd...](https://blog.mozilla.org/security/2016/01/06/man-in-the-middle-
interfering-with-increased-security/)

Other configs worth doing:

`security.ssl.treat_unsafe_negotiation_as_broken` to `true` and
`security.ssl.require_safe_negotiation` to `true` also. Refusing insecure
algorithms (`security.ssl3.<alg>`) might also be smart.

