> 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
> 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.
> 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.
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.
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.
>...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
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.
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).
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?
`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.
