On Tue, 29 Apr 2008, Geoffrey Irving wrote: > On Tue, Apr 29, 2008 at 10:55 AM, Nicolas Pitre <nico@xxxxxxx> 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* -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
