Hem , sha-3 i suppose, keccak, no ? But really is not so urgent as you have already told . Best 2012/10/15, Jeff King <peff@xxxxxxxx>: > On Mon, Oct 15, 2012 at 07:47:09PM +0200, Ævar Arnfjörð Bjarmason wrote: > >> On Mon, Oct 15, 2012 at 6:42 PM, Elia Pinto <gitter.spiros@xxxxxxxxx> >> wrote: >> > Very clear analysis. Well written. Perhaps is it the time to update >> > http://git-scm.com/book/ch6-1.html (A SHORT NOTE ABOUT SHA-1) ? >> > >> > Hope useful >> > >> > http://www.schneier.com/crypto-gram-1210.html >> >> This would be concerning if the Git security model would break down if >> someone found a SHA1 collision, but it really wouldn't. >> >> It's one thing to find *a* collision, it's quite another to: >> >> 1. Find a collision for the sha1 of harmless.c which I know you use, >> and replace it with evil.c. >> >> 2. Somehow make evil.c compile so that it actually does something >> useful and nefarious, and doesn't just make the C compiler puke. >> >> If finding one arbitrary collision costs $43K in 2021 dollars >> getting past this point is going to take quite a large multiple of >> $43K. > > There are easier attacks than that if you can hide arbitrary bytes > inside a file. It's hard with C source code. The common one in hash > collision detection circles is to put invisible cruft into binary > document formats like PDF or Postscript. Git blobs themselves do not > have such an invisible place to put it, but you might be storing a > format that does. > > But worse, git _commits_ have such an invisible portion. We calculate > the sha1 over the full commit, but we tend to show only the portion up > to the first NUL byte. I used that horrible trick in my "choose your own > sha1 prefix" patch. However, we could mitigate that by checking for > embedded NULs in git-fsck. > >> 3. Somehow inject the new evil object into your repository, or >> convince you to re-clone it / clone it from somewhere you usually >> wouldn't. > > Yeah, this part is the kicker. With the commit NUL trick, you would make > a useful commit and then ask somebody to pull it, and then later replace > it with a commit pointing to an arbitrary tree. But if we assume we can > detect that easily (which I think we can), we are left with replacing > binary blobs that have hidden bits. And most projects do not take many > such blobs, and the result is that you could only replace the contents > of that particular blob, not an arbitrary part of the tree. > >> It would be very interesting to see an analysis that deals with some >> actual Git-related security scenarios, instead of something that just >> assumes that if someone finds *any* SHA1 collision the sky is going to >> fall. > > I agree that most of the analysis is overblown. Having read the analysis > Schneier pointed to, it actually is not that bad. We have 5-10 years to > get to a point where it's really expensive and extremely complex to > mount a single attack. > > That doesn't seem like an emergency to me. It sounds like something we > should be thinking about (and we are). The simplest thing would be to > wait for a moment when it makes sense to break compatibility (e.g., we > decide that "git 2.0" is here, and everybody will have to rewrite to > take advantage of new features, so we can jump to sha-2). We can also > start building sha-2 history that references sha-1 history. That would > mean everybody needs to upgrade their git, but that is not a problem > that requires 5-10 years of foresight and planning. > > -Peff > -- Inviato dal mio dispositivo mobile -- 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