On 4/21/07, Karl Hasselström <kha@xxxxxxxxxxx> wrote:
Well, any hash is "incomplete" or "not long enough" inasmuch as it's theoretically possible to find collisions. The choice of the full 160 bits (note: this is 20 bytes, not 40) is arbitrary -- it's just "long enough". 128 bits would have been enough to prevent any naturally occurring collisions, too (maybe even 96 bits would be enough, I'm too lazy to do the math). The only reason to go as high as 160 is to prevent any possible collision created by a malicious adversary, too, so that it's possible to e.g. sign just a commit and be able to trust everything it points to. The SHA1 designers felt that 160 bits was a good compromise between size and robustness, and we just trust that their (and the cryptographic community's) guess is good enough.
I think it is sensible to differentiate between - creation of a 160bits possible unique signature - use of whole 160bits signature to reference the object I'm wondering that as long as we are able to calculate on the fly the whole 160 bits signature from the object when needed then the second point _could_ be relaxed and we could use a truncated sha (note that is not a new sha calculated with less bits, it is the good old 160bits sha just trucated to be used as object reference). This could be convenient as long as collision is very unlikely, so to work almost always with abbrev forms and fallback on full 160bits on those rare cases. Marco - 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