On Tue, Apr 29, 2008 at 7:37 AM, Andreas Ericsson <ae@xxxxxx> wrote: > > Paolo Bonzini wrote: > > > > > > > > I can think of one way to make git a lot more resilient to hash > > > collisions, regardless of which hash is used, namely: Add the length > > > of the hashed object to the hash. > > > > > > > Not really, because most attacks are about collisions, not second > preimages. They produce two 64-byte blocks (hence, same length) with the > same hash value. > > > > As such, they allow to change a blob that *the attacker* injected in the > repository. The way the more "spectacular" attacks are devised requires a > "language" with conditional expressions -- for documents, for example, > Postscript is used. If you prepare a postscript file whose code is > > > > if (AAAA == BBBB) > > typeset document 1 > > else > > typeset document 2 > > > > where AAAA and BBBB are collisions, and you change it to "if (BBBB == > BBBB) the hash will be the same, but the outcome will be document 1 instead > of document 2. > > > > The fact that this requires having the two "behaviors" in the blob is not > a big deal for source code, going in the wrong branch of an "if" can be an > attack. On the other hand, it makes adding the length useless for collision > attacks. True, it wouldn't be useless for second preimage attacks, but > SHA-1 is still secure with respect to those. > > > > > > So what you're saying is that if someone owns a repository and adds a > file to it, he can then replace his entire repository with an identical > one where the good file is replaced with a bad one, and this will affect > people who clone *after* the file gets replaced. > No, if someone 0wnz a repository, not owns (Or really, malicious mirror owners could be in on it). Either that or some form of redirection attack. When you download a tarball, you can check the signed checksum that is downloadable along with it. When you clone a repo, you depend on signed tags. -- 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