Re: About git and the use of SHA-1

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Apr 29, 2008, 18:41 UTC
Message-ID: <alpine.LNX.1.00.0804291410340.19665@iabervon.org>
In-Reply-To: <7f9d599f0804291102j4a30c344h18d12d03a6d5953b@mail.gmail.com>

On Tue, 29 Apr 2008, Geoffrey Irving wrote:

Show 14 quoted lines

> On Tue, Apr 29, 2008 at 10:55 AM, Nicolas Pitre <nico@cam.org> wrote:
> > On Tue, 29 Apr 2008, Geoffrey Irving wrote:
> >
> >
> > > Sorry for the confusion: it would handwaving if I was saying git was insecure,
> >  > but I'm not.  I'm saying that if or when SHA1 becomes vulnerable to collision
> >  > attacks, git will be insecure.
> >
> >  Right.  And if or when that happens then we'll make Git secure again
> >  with a different hash.  In the mean time there is low return for the
> >  effort involved.
> 
> Yes.  I wasn't trying to advocate switching, just making sure people
> know that the "collisions don't matter" argument is bogus.

It's bogus to say they completely don't matter, but I still claim that they don't matter for the things people actually care about. If people can generate collisions, they can commit a "weak" blob with a conditional that can be switched by replacing the blob. But it's almost always true that people could commit a blob with a conditional that can be switched by something else under the attacker's more direct control. Using a better hash function won't save you from a document like:

if (getdate() < 2009)
  render_good_text
else
  render_evil_text

even if it does help with:

if (AA == AA)
  render_good_text
else
  render_evil_text

If you're not checking your files for the former, you shouldn't worry about the latter, because the former is much easier and more subtle.

(Now, an arbitrary preimage attack would actually be significant, still, because the attacker could replace an honestly-created "restrictive security policy" file with garbage that will be ignored, leaving stuff unprotected)

	-Daniel
*This .sig left intentionally blank*