[cryptography] kernel.org hack and kernel integrity
jon at callas.org
Sat Sep 3 19:14:41 EDT 2011
> 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.
More information about the cryptography