Re: Why SHA are 40 bytes? (aka looking for flames)

From: Karl Hasselström <kha@treskal.com>
Date: Apr 21, 2007, 16:53 UTC
Message-ID: <20070421165331.GA5080@diana.vm.bytemark.co.uk>
In-Reply-To: <200704211608.06171.andyparkins@gmail.com>

On 2007-04-21 16:08:01 +0100, Andy Parkins wrote:

Show 10 quoted lines

> 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@treskal.com
      www.treskal.com/kalle