On 4/21/07, Karl Hasselström <kha@treskal.com> wrote:
Show 13 quoted lines
> > 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