You don't understand the fingerprint argument. For the specific SHA-1 attack, it's possible to detect, while calculating the SHA-1 hash of an object, whether the bit pattern indicative of this specific attack is present. This is done automatically, without needing any human intervention. This is one of the things which Google released immediately as part of their announcement.

The other thing which people seem to miss is that it requires 6,500 years of GPU computation for the _first_ phase of the SHA1 attack, and 110 years of the GPU compatation for the _second_ phase of the attack. You need to do both phases in order successfully carry out this attack. And even if you do, Google released code so that someone can easily tell if the object they were hashing was one created using this parituclar attach, which required 6,500 + 110 years of GPU computation.

But alas, it's a lot more fun to run around screaming that the sky is falling.....

Thanks, I was wrong when saying "fingerprinting". The fingerprinting technique is actually quite reassuring. I was thinking of that he says

"But if you use git for source control like in the kernel, the stuff you really care about is source code, which is very much a transparent medium. If somebody inserts random odd generated crud in the middle of your source code, you will absolutely notice. " , which I still think is a very weak argument.

It might or might not be true for any particular developer, and his argument does not refute the claim that the SHA1 integrity checks for that code is being rendered useless. I specifically recall that Linus previously described the hashed chain of commits as something which would prevent malicious insertion of code. And this has now, at least to some degree, been compromised.

He did provide some solid countermeasures and migration plans, but I think he could have been more acknowledging to all the people who predicted this attack. It would have been a good idea to prepare for changing hash function eventually.

keep in mind you have to maintain/commit the initial blob and then later the malicious one (again and again, this is no pre-image attack - the initial blob has to have a well designed place with random jazz ready to be replaced)

You could just place a malicious one from the get go and no one would know (or they would know just as much -- blob do rely on virtually unconditional trust)

There is already danger in accepting unreadable content by itself.

True. But I thought that the point of the hashes was to ensure that something which you had already verified (through review or testing or whatever) could not be tampered with without the changes being brought to your attention. And this property does no longer hold.

Yeah, but in your case you would just get the binary, verify it and push it yourself.

If you're using some weird way of getting a binary that you have already verified, but that could somehow differ, and you're hopping that git will catch the difference, you're doing it wrong to begin with.

He doesn't mean manually recognising the fingerprint

Correct. He's talking about the automated method used on shattered.io to detect files which use the attack. See: https://github.com/cr-marcstevens/sha1collisiondetection

They're basically building that into git so that if this specific collision attack is ever used, git will notice and throw a warning/error.

Thanks, I misread that. I meant that he says

"But if you use git for source control like in the kernel, the stuff you really care about is source code, which is very much a transparent medium. If somebody inserts random odd generated crud in the middle of your source code, you will absolutely notice. "

, which I think is a very weak argument.

Please PoC a Git exploit then?

Sure, just wire me 200k.

If you're working on such a massively important git repo with very poor security measures and trust levels at $200k break in status that are practical... yeah, maybe bigger problems.

I'g glad you're willing to discuss things so freely /s