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.
Gee, that's one fiendishly large attack vector, quite apart from the
fact that said author first has to come up with a program that gets
widespread enough that a lot of people all of a sudden wants to use
it, but not so widespread that anyone would want to review it before
using it.
I remain unconvinced as to whether or not SHA1 is, for all practical
purposes, cryptographically secure for git's uses. Sure, evil programmers
can screw you over if you use their software without reviewing it, but
that's hardly due to git using a particular cryptographic algorithm.
Otoh, I'm not familiar enough with the nomenclature to say with 100%
certainty what's cryprographically secure and what isn't. I just know
that there are no collision-less hashes, so whatever "cryptographically
secure" really means wrt hashes, "100% collision-free" isn't it.
--
Andreas Ericsson andreas.ericsson@xxxxxx
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
--
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
