On 2007-04-21 16:08:01 +0100, Andy Parkins wrote:
> On Saturday 2007, April 21, Marco Costalba wrote:
>
> > Well, why to store always the full length SHA?
>
> Well apart from being easier than working out the optimum size for
> every single object write, one really good reason would be that
> there is no way to predict that an object in the future won't have a
> conflicting SHA - every object /has/ to be stored with its full
> hash, because you are preventing conflicts with everything object
> now, in the past and all possible futures.
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.
--
Karl Hasselström, kha@xxxxxxxxxxx
www.treskal.com/kalle
-
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