The first chosen-prefix collision for SHA-1
sha-mbles.github.io
The first chosen-prefix collision for SHA-1
1–10 of 369 posts
Re: The first chosen-prefix collision for SHA-1
#2Q: Does this make it even more urgent for git to move to a different hash?
Re: The first chosen-prefix collision for SHA-1
#3[deleted]
Re: The first chosen-prefix collision for SHA-1
#4Q: Does this make it even more urgent for git to move to a different hash?
A: (from the article)
SHA-1 has been broken for 15 years, so there is no good reason to use this hash function in modern security software. Attacks only get better over time, and the goal of the cryptanalysis effort is to warn users so that they can deprecate algorithms before the attacks get practical. We actually expect our attack to cost just a couple thousand USD in a few years.
Re: The first chosen-prefix collision for SHA-1
#5Q: Does this make it even more urgent for git to move to a different hash?
It may, because now an attacker can replace code with arbitrary other valid code as long as developers are willing to ignore the long weird random comment at the end ;-)
I’m gonna say many developers will not care but and many compilers will not care either.
So yeah, Linus’ main deterrent reason (code won’t compile) doesn’t apply anymore.
HOWEVER!
1. A chosen-prefix attack still needs to compute TWO suffixes m1 and m2 so that h(a1+m1) = h(a2+m2). This does NOT mean that given a1 and a2 you can find a single m2 so that h(a1) = h(a2+m2). So that ONLY THE ORIGINAL AUTHOR OF THE COMMIT could spoof their own commit, by preparing in advance and attaching a long and weird comment in the end. And you could build tools to watch out for such commits in the first place
2. If git had used HMAC based on SHA1 then it would have been fine, even after this attack has become feasible.
3. Furthermore, it is likely still kinda fine because Merkle Trees have nodes referencing previous nodes. You’d have to spoof every historical node as well, to push malicious code. BitTorrent also requires computers to supply an entire merkle branch when serving file chunks.
Maybe someone can elaborate on this.
Re: The first chosen-prefix collision for SHA-1
#6Q: Does this make it even more urgent for git to move to a different hash?
It adds to the weight of the argument, but there isn't a big issue. This article (https://www.zdnet.com/article/linus-torvalds-on-sha-1-and-gi...) and the linked email (https://marc.info/?l=git&m=148787047422954) both seem to still apply.
Re: The first chosen-prefix collision for SHA-1
#7Quick question about the "What should I do" section. It says "use instead SHA-256". Isn't SHA-512 both better and faster on modern hardware?
Re: The first chosen-prefix collision for SHA-1
#8Q: Does this make it even more urgent for git to move to a different hash?
It may, because now an attacker can replace code with arbitrary other valid code as long as developers are willing to ignore the long weird random comment at the end ;-) I’m gonna say many developers will not care but and many compilers will not care either. So yeah, Linus’ main deterrent reason (code won’t compile) doesn’t apply anymore. HOWEVER! 1. A chosen-prefix attack still needs to compute TWO suffixes m1 and m…
If you look in this 2017 (https://marc.info/?l=git&m=148787047422954) email from Linux, he discusses how git also encodes length. That would mean that you need a collision of the same length and the right functionality, so you can't just append data.
Re: The first chosen-prefix collision for SHA-1
#9Q: Does this make it even more urgent for git to move to a different hash?
There is a migration path to SHA-256, see a good summary here: https://stackoverflow.com/a/47838703/109517
See a previous discussion here, regarding Linus's position on this in 2017: https://news.ycombinator.com/item?id=13719368
Re: The first chosen-prefix collision for SHA-1
#10Q: Does this make it even more urgent for git to move to a different hash?
It adds to the weight of the argument, but there isn't a big issue. This article ( https://www.zdnet.com/article/linus-torvalds-on-sha-1-and-gi... ) and the linked email ( https://marc.info/?l=git&m=148787047422954 ) both seem to still apply.
Further details as to why Torvalds is not concerned:
From the email...
"I haven't seen the attack yet, but git doesn't actually just hash the data, it does prepend a type/length field to it. That usually tends to make collision attacks much harder, because you either have to make the resulting size the same too, or you have to be able to also edit the size field in the header."
[...]
"I haven't seen the attack details, but I bet
(a) the fact that we have a separate size encoding makes it much harder to do on git objects in the first place
(b) we can probably easily add some extra sanity checks to the opaque data we do have, to make it much harder to do the hiding of random data that these attacks pretty much always depend on."