> One thing I've been curious about is what would have to happen in the
> world of git when (a) someone shows how to construct SHA-1 hash
> collisions, or (b) someone shows how to consturct SHA-1 second
> preimages. There is a "repositoryformatversion = 0" in the on-disk
> format. I'm not sure if there are any other mechanisms in git storage
> or communication formats for crypto hash agility. (I expect there is
> no code in git that anticipates needing crypto hash agility.)
When someone shows how to construct SHA1 second preimages, please include me in
the demo, as doing that remains an unsolved problem.
I do not mean to defend SHA1 at all, heck, give me half a chance and I'll tell
you to drop in Skein. Nonetheless, there are still zero second-preimage attacks
on SHA1.
Operationally, however, if you could reliably create SHA1 second preimages as a
zero-day (by which I mean that no one else in the world can do it, so you get
to surprise the world), this isn't the place to do it.
With digital signatures, you can have a lot of fun with second preimages. If
there's a signature S on preimage P, then if I own P', I can claim it's signed.
Why bother compromising a CA if you can clone a certificate, for example?
With any sort of content-addressable storage, however, it doesn't work so well.
Suppose I create some malware as my P'. When I push this into the off-host, the
other system will say, "I already have P, thanks" and won't get P' from me. In
the case of a central repository, I can't push P' into it because it will
always refuse it for the simple reason that it has it.
In the case of something like git, we end up with a partitioned set of
repositories, and the only people who get P' are the ones who didn't have it
and pull it from me (or I push it on them when they don't have P). The details
of the spread depend on lots of things not worth discussing.
Bottom line on this is that if you can make SHA1 collisions, breaking content
addressable storage isn't worth blowing your lead on. Abstractly, git ought to
become agile in hash function, but realistically, it's not a concern yet.
Jon
_______________________________________________
cryptography mailing list
[email protected]
http://lists.randombit.net/mailman/listinfo/cryptography
