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
> 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.
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.
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.
https://arstechnica.com/security/2017/02/at-deaths-door-for-...
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.
http://stackoverflow.com/questions/9392365/how-would-git-han...
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.See the end of his post: "He did show some concern that there might be a way to crack the algorithm"
They got a lot of flak for trying to deprecate it "so early". It's nice to see them proving everyone wrong on this.
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...
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.