--On Sunday, August 27, 2006 03:35:20 PM -0700 Linus Torvalds <torvalds@osdl.org> wrote: > > On Mon, 28 Aug 2006, Johannes Schindelin wrote: >> Even if the breakthrough really comes to full SHA-1, you still have to >> add _at least_ 20 bytes of gibberish. Which would be harder to spot, >> but it would be spotted. > > Yeah, I don't think this is at all critical, especially since git really > on a security level doesn't _depend_ on the hashes being > cryptographically secure. As I explained early on (ie over a year ago, > back when the whole design of git was being discussed), the _security_ > of git actually depends on not cryptographic hashes, but simply on > everybody being able to secure their own _private_ repository. > > So the only thing git really _requires_ is a hash that is _unique_ for > the developer (and there we are talking not of an _attacker_, but a > benign participant). > > That said, the cryptographic security of SHA-1 is obviously a real bonus. > So I'd be disappointed if SHA-1 can be broken more easily (and I > obviously already argued against using MD5, exactly because generating > duplicates of that is fairly easy). But it's not "fundamentally > required" in git per se. >> This made me think about the use of hashes in git. Why do we need a hash >> here (in no particular order): >> >> 1) integrity checking, >> 2) fast lookup, >> 3) identifying objects (related to (2)), >> 4) trust. >> >> Except for (4), I do not see why SHA-1 -- even if broken -- should not >> be adequate. It is not like somebody found out that all JPGs tend to >> have similar hashes so that collisions are more likely. > > Correct. I'm pretty sure we had exactly this discussion around May 2005, > but I'm too lazy to search ;) just to double check. if you already have a file A in git with hash X is there any condition where a remote file with hash X (but different contents) would overwrite the local version? what would happen if you ended up with two packs that both contained a file with hash X but with different contents and then did a repack on them? (either packs from different sources, or packs downloaded through some mechanism other then the git protocol are two ways this could happen that I can think of) David Lang - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.htmlReceived on Tue Aug 29 03:42:31 2006
This archive was generated by hypermail 2.1.8 : 2006-08-29 03:45:08 EST