Linus' reply on Git and SHA-1 collision

Re:Linus' reply on Git and SHA-1 collision by hvidgaard on Friday February 24, 2017 @03:18AM (#13721984)

The length field makes the attack significantly more difficult. In the publish attack, you take 2 fixed input and prepend special data to make the collision. With Git, you have additional constraint. Either it needs to be of exact length, this may or may not be an issue, but most likely is unless we find a new weakness in SHA-1, or you must be able to handle the changing input.

In all the examples in your link, while true that you can add "silent data" to all of the examples, they are all examples of structured data. So not only do you have to figure out the collision, you have to do so within the structure of the format you're attacking. This is a lot harder than just prepending the exact bytes you want.

[ Parent | on HN ]

Re:Linus' reply on Git and SHA-1 collision by jwilk on Friday February 24, 2017 @04:33AM (#13722271)

> The length field makes the attack significantly more difficult. In the publish attack, you take 2 fixed input and prepend special data to make the collision.

That's not how the attack works. Not at all.

[ Parent | on HN ]

Re:Linus' reply on Git and SHA-1 collision by hvidgaard on Friday February 24, 2017 @05:06AM (#13722433)

If you ignore the prepend part, it is in essence taking known input and calculate a collision.

> This is an identical-prefix collision attack, where a given prefix P is extended with two distinct near-collision block pairs such that they collide for any suffix S.

And

> Our example colliding files only differ in two successive random-looking message blocks generated by our attack. We exploit these limited differences to craft two colliding PDF documents containing arbitrary distinct images.

[ Parent | on HN ]