> 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.
>...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.
> 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.
`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.
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.
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?
Crazy I have met a lot of fraudsters claiming to be hackers but kept ripping me off money, not until I met one off the darkweb who brought me out of my mystery and reuniting my wife back to me. I have forgiven her for all her disloyalty and atrocities he did in the past. Why not tell your situation to this hacker, he just might be your savior also. Besides I guess he does other hacking services (grades change, phone cloning, emails hacking and so on). text 19193076946 or darkwebsolutions at hackermail dot com
27 comments
[ 9.5 ms ] story [ 124 ms ] threadhttps://news.ycombinator.com/item?id=13713557
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.
> 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.
http://stackoverflow.com/questions/9392365/how-would-git-han...
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.
They got a lot of flak for trying to deprecate it "so early". It's nice to see them proving everyone wrong on this.
Copy-pasting for posterity:
See the end of his post: "He did show some concern that there might be a way to crack the algorithm"