Re: SHA1 collisions found
- From
Linus Torvalds <torvalds@linux-foundation.org>
- Date
- Feb 23, 2017, 18:40 UTC
- Message-ID
- <CA+55aFxckeEW1ePcebrgG4iN4Lp62A2vU6tA=xnSDC_BnKQiCQ@mail.gmail.com>
- In-Reply-To
- <20170223182147.hbsyxsmyijgkqu75@kitenet.net>
On Thu, Feb 23, 2017 at 10:21 AM, Joey Hess <id@joeyh.name> wrote:
Show 9 quoted lines
> Linus Torvalds wrote: >> What you describe pretty much already requires a pre-image attack, >> which the new attack is _not_. >> >> It's not clear that the "good" object can be anything sane. > > Generate a regular commit object; use the entire commit object + NUL as the > chosen prefix, and use the identical-prefix collision attack to generate > the colliding good/bad objects.
So I agree with you that we need to make git check for the opaque data. I think I was the one who brought that whole argument up.
But even then, what you describe doesn't work. What you describe just replaces the opaque data - that git doesn't actually *use*, and that nobody sees - with another piece of opaque data.
You also need to make the non-opaque data of the bad object be something that actually encodes valid git data with interesting hashes in it (for the parent/tree/whatever pointers).
So you don't have just that "chosen prefix". You actually need to also fill in some very specific piece of data *in* the attack parts itself. And you need to do this in the exact same size (because that's part of the prefix), etc etc.
So I think it's challenging.
... and then we can discover it trivially.
Ok, so "git fsck" right now takes a couple of minutes for me and I don't actually run it very often (I used to run it religiously back in the days), but afaik kernel.org actually runs it nightly. So it's pretty much "trivially discoverable" - imagine spending thousands of CPU-hours and lots of social capital to get an attack in, and then the next night the kernel.org fsck complains about the strange commit you added?
Linus