Re: SHA1 collisions found
- From
Joey Hess <id@joeyh.name>
- Date
- Feb 23, 2017, 17:35 UTC
- Message-ID
- <20170223173547.qljypk7sdqi37oha@kitenet.net>
- In-Reply-To
- <CAPc5daVZ79WWKSw76kxHgDra9a7fSR1AibZa_pvK9aUuuVawLQ@mail.gmail.com>
Junio C Hamano wrote:
Show 7 quoted lines
> On Thu, Feb 23, 2017 at 8:43 AM, Joey Hess <id@joeyh.name> wrote: > > > > Since we now have collisions in valid PDF files, collisions in valid git > > commit and tree objects are probably able to be constructed. > > That may be true, but > https://public-inbox.org/git/Pine.LNX.4.58.0504291221250.18901@ppc970.osdl.org/
That's about someone replacing an valid object in Linus's repository with an invalid random blob they found that collides. This SHA1 break doesn't allow generating such a blob anyway. Linus is right, that's an impractical attack.
Attacks using this SHA1 break will look something more like:
* I push a "bad" object to a repo on github I set up under a pseudonym. * I publish a "good" object in a commit and convince the maintainer to merge it. * I wait for the maintainer to push to github. * I wait for github to deduplicate and hope they'll replace the good object with the bad one I pre-uploaded, thus silently changing the content of the good commit the maintainer reviewed and pushed. * The bad object is pulled from github and deployed. * The maintainer still has the good object. They may not notice the bad object is out there for a long time.
Of course, it doesn't need to involve Github, and doesn't need to rely on internal details of their deduplication[1]; that only let me publish the bad object under a psydonym.
--
see shy jo
[1] Which I'm only guessing about, but now that we have colliding
objects, we can upload them to different repos and see if such
dedupication happens.