|
||
|
3 September 2011 SHA1 second preimages remain an unsolved problem
From: Jon Callas <jon[at]callas.org> Tim Shepard wrote:
> One thing I've been curious about is what would have to happen in
the 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
|