Thread

1. bawolff · 1790906657 · focus · HN ↗

   I think the only good argument here is that sha is maybe not a security control for git. I think every other argument in this article is incorrect

   a) it's relatively fast and impossible in a practical sense for two different files to accidentally hash to the same value.

   That is silly. We are not worried about accidentally triggering. We are worried about intentional triggers.

   I dont know why people always bring this up for hashing. In any other context it would be considered silly. If someone said, the chance of triggering a buffer overflow by accident is low, we would call that silly as we aren't worried about accidental triggers.

   b) second pre-image vs collision. In a world of open source where we accept commits from randoms on the internet, i think collisions are just as relavent as second pre-image.

   1. eviks · 1790907727 · focus · HN ↗

      a) it's silly to stop reading at that quote because the following text deals with "identification"

      b) so, you agree with the blog? "So, any realistic interesting attack vector therefore relies on a collision attack,"

      1. bawolff · 1790912301 · focus · HN ↗

         > b) so, you agree with the blog? "So, any realistic interesting attack vector therefore relies on a collision attack,"

         My reading of the blog is that they are dismissive of collision attacks. In context of git, i disagree. I think there are plausible attack scenarios involving collisions, or at least, just as plausible as second pre-image.

         If you mean do i agree with the blog that impossible attacks aren't possible? well yes obviously, but i think that goes without saying.

Unofficial Hacker News client; not affiliated with Y Combinator.