2
votes

I have a sha-160 computation that gives me a 160 bit hash of my data, but I expect this is way larger than necessary. So I'm thinking I could truncate the resulting hash down to say the low 64 bits and use that.

Does taking the low 64 bits of a sha-160 hash computation give a reasonably random 64 bit hash?

1
So, you will gain 12 bytes? For what kind of application is it? - ypercubeᵀᴹ
In cases like this, rather than truncate, I prefer to XOR-fold. In both cases the analyzed cypto-properties of the SHA-160 should be considered to be "tossed away". In the folding method, all the bits are used in some fashion, however. In both cases if the SHA-160 is considered to be uniformly distributed, doubt it makes a difference. The number of unique values in 64-bits is still quite ... large ... but not so sure if I'd use it as a guarantee-no-collisions method. - user166390
@pst There's really no need to fold - as long as the underlying hash is secure, any subset of bits is sufficient. If the hash isn't secure, folding isn't likely to help you much. - Nick Johnson

1 Answers

5
votes

Part of what it means for something to be a good hash is that any fixed subset of its bits is also (so far as possible, given how many bits) a good hash. The low 64 bits of a SHA-160 hash should be a good 64-bit hash, in so far as there is such a thing.

Note that for some purposes 64 bits really isn't all that many. For instance, if anything breaks in your application when someone finds two different things with the same hash, you probably want something longer: on average it will only take a modest number of billions of trials to find two things with the same 64-bit hash, no matter what your hashing algorithm.

What bad thing would happen if you just used all 160 bits?