6 ms·

Q: Does this make it even more urgent for git to move to a different hash?

by 0x0 7y ago

LeonM 7y ago
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.
- pathseeker 7y ago
  That's not a relevant answer. Git's use-case is very specific and it's quite possible that this attack won't be relevant. It needs analysis. >no good reason to use this hash function in modern security software This argument conveniently ignores the cost to switching existing software (i.e. it's completely detached from reality).
EGreg 7y ago
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.
- rkangel 7y ago
  If you look in this 2017 (https://marc.info/?l=git&m=148787047422954 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.
  - toyg 7y ago
    Now that you can arbitrarily produce collisions, the second step is easy enough for a skilled and well-funded attacker.
rkangel 7y ago
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-git-the-sky-isnt-falling/ https://www.zdnet.com/article/linus-torvalds-on-sha-1-and-gi...) and the linked email (https://marc.info/?l=git&m=148787047422954 https://marc.info/?l=git&m=148787047422954) both seem to still apply.
- groovybits 7y ago
  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."
  - wyldfire 7y ago
    I think those are pretty practical approaches. But it sounds as if the cost of changing the hash algorithm is high. What are the impacts of this change? How many things would break if git just changed the algorithm with each new release? Does git assume that the hash algorithm is statically given to be SHA-1 or are there qualifiers on which algorithm is enabled/permitted/configured?
    - paulddraper 7y ago
      After making the actual code change, the biggest problem is breaking compatibility with decades of tools in the ecosystem that rely on historically consistent SHA-1 hashes. Git is moving to a flexible hash though. [1] [1] https://stackoverflow.com/questions/28159071/why-doesnt-git-use-more-modern-sha/47838703#47838703 https://stackoverflow.com/questions/28159071/why-doesnt-git-...
mikepurvis 7y ago
There is a migration path to SHA-256, see a good summary here: https://stackoverflow.com/a/47838703/109517 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 https://news.ycombinator.com/item?id=13719368
rom1v 7y ago
What happens if you actually get a SHA-1 collision in git? -> https://stackoverflow.com/questions/9392365/how-would-git-handle-a-sha-1-collision-on-a-blob https://stackoverflow.com/questions/9392365/how-would-git-ha... (This does not answer your question, but is still interesting.)
mzs 7y ago
https://news.ycombinator.com/item?id=21985773 https://news.ycombinator.com/item?id=21985773

Q: Does this make it even more urgent for git to move to a different hash?

by 0x0 7y ago

Q: 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.

pathseeker 7y ago
That's not a relevant answer. Git's use-case is very specific and it's quite possible that this attack won't be relevant. It needs analysis. >no good reason to use this hash function in modern security software This argument conveniently ignores the cost to switching existing software (i.e. it's completely detached from reality).

EGreg 7y ago

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.

rkangel 7y ago
If you look in this 2017 (https://marc.info/?l=git&m=148787047422954 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.
- toyg 7y ago
  Now that you can arbitrarily produce collisions, the second step is easy enough for a skilled and well-funded attacker.

rkangel 7y ago

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-git-the-sky-isnt-falling/ https://www.zdnet.com/article/linus-torvalds-on-sha-1-and-gi...) and the linked email (https://marc.info/?l=git&m=148787047422954 https://marc.info/?l=git&m=148787047422954) both seem to still apply.

groovybits 7y ago
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."
- wyldfire 7y ago
  I think those are pretty practical approaches. But it sounds as if the cost of changing the hash algorithm is high. What are the impacts of this change? How many things would break if git just changed the algorithm with each new release? Does git assume that the hash algorithm is statically given to be SHA-1 or are there qualifiers on which algorithm is enabled/permitted/configured?
  - paulddraper 7y ago
    After making the actual code change, the biggest problem is breaking compatibility with decades of tools in the ecosystem that rely on historically consistent SHA-1 hashes. Git is moving to a flexible hash though. [1] [1] https://stackoverflow.com/questions/28159071/why-doesnt-git-use-more-modern-sha/47838703#47838703 https://stackoverflow.com/questions/28159071/why-doesnt-git-...

mikepurvis 7y ago

There is a migration path to SHA-256, see a good summary here: https://stackoverflow.com/a/47838703/109517 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 https://news.ycombinator.com/item?id=13719368

rom1v 7y ago

What happens if you actually get a SHA-1 collision in git? -> https://stackoverflow.com/questions/9392365/how-would-git-handle-a-sha-1-collision-on-a-blob https://stackoverflow.com/questions/9392365/how-would-git-ha... (This does not answer your question, but is still interesting.)

mzs 7y ago

https://news.ycombinator.com/item?id=21985773 https://news.ycombinator.com/item?id=21985773