Re: SHA1 collisions found
- From
Linus Torvalds <torvalds@linux-foundation.org>
- Date
- Feb 23, 2017, 17:52 UTC
- Message-ID
- <CA+55aFzFEpi1crykZ33r9f7BsvLt_kiB-CHXOkuCAX=fd4BU-w@mail.gmail.com>
- In-Reply-To
- <20170223173547.qljypk7sdqi37oha@kitenet.net>
On Thu, Feb 23, 2017 at 9:35 AM, Joey Hess <id@joeyh.name> wrote:
> > Attacks using this SHA1 break will look something more like:
We don't actually know what the break is, but it's likely that you can't actually do what you think you can do:
> * 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.
It's not clear that the "good" object can be anything sane.
What you describe pretty much already requires a pre-image attack, which the new attack is _not_.
The new attack doesn't have a controlled "good" case, you need two different objects that both have "near-collision" blocks in the middle. I don't know what the format of those near-collision blocks are, but it's a big problem.
You blithely just say "I create a good object". It's not that simple. If it was, this would be a pre-image attack.
So basically, the attack needs some kind of random binary garbage in *both* objects in the middle.
That's why pdf's are the classic model for showing these attacks: it's easy to insert garbage in the middle of a pdf that is invisible.
In a psf, you can just define a bitmap that you don't use for printing - but you can use them to then make a decision about what to print - making the printed version of the pdf look radically different in ways that are not so much _directly_ about the invisible block itself.
Linus