From: Jeff King <peff@peff.net>
To: git@vger.kernel.org
Cc: Shawn Pearce <spearce@spearce.org>,
Michael Hirshleifer <111mth@caltech.edu>
Subject: Re: Possible vulnerability to SHA-1 collisions
Date: Tue, 27 Nov 2012 19:27:14 -0500 [thread overview]
Message-ID: <20121128002714.GA23224@sigill.intra.peff.net> (raw)
In-Reply-To: <20121127233016.GC3937@pug.qqx.org>
On Tue, Nov 27, 2012 at 06:30:17PM -0500, Aaron Schrab wrote:
> At 18:07 -0500 27 Nov 2012, Jeff King <peff@peff.net> wrote:
> >PS I also think the OP's "sockpuppet creates innocuous bugfix" above is
> > easier said than done. We do not have SHA-1 collisions yet, but if
> > the md5 attacks are any indication, the innocuous file will not be
> > completely clean; it will need to have some embedded binary goo that
> > is mutated randomly during the collision process (which is why the
> > md5 attacks were demonstrated with postscript files which _rendered_
> > to look good, but contained a chunk of random bytes in a spot ignored
> > by the postscript interpreter).
>
> I don't think that really saves us though. Many formats have parts
> of the file which will be ignored, such as comments in source code.
Agreed, it does not save us unconditionally. It just makes it harder to
execute the attack. Would you take a patch from a stranger that had a
kilobyte of binary garbage in a comment?
A more likely avenue would be a true binary file where nobody is
expected to read the diff.
> With the suggested type of attack, there isn't a requirement about
> which version of the file is modified. So the attacker should be
> able to generate a version of a file with an innocuous change, get
> the SHA-1 for that, then add garbage comments to their malicious
> version of the file to try to get the same SHA-1.
That's not how birthday collision attacks usually work, though. You do
not get to just mutate the malicious side and leave the innocuous side
untouched. You are mutating both sides over and over and hoping to find
a matching sha1 from the "good" and "evil" sides.
Of course, I have not been keeping up too closely with the efforts to
break sha-1. Maybe there is something more nefarious about the current
attacks. I am just going off my recollection of the md5 collision
attacks.
-Peff
next prev parent reply other threads:[~2012-11-28 0:27 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-24 11:12 Possible vulnerability to SHA-1 collisions Michael Hirshleifer
2012-11-24 18:09 ` Shawn Pearce
2012-11-27 23:07 ` Jeff King
2012-11-27 23:30 ` Aaron Schrab
2012-11-28 0:27 ` Jeff King [this message]
2012-11-28 9:35 ` Andreas Ericsson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20121128002714.GA23224@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=111mth@caltech.edu \
--cc=git@vger.kernel.org \
--cc=spearce@spearce.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).