[OT] Reasons not to use multiple hash functions for "more security"

Matthieu Moy Matthieu.Moy at imag.fr
Mon Jan 22 12:53:46 GMT 2007


John Arbash Meinel <john at arbash-meinel.com> writes:

> 2) Much worse than a single well designed hash of the total length. So
> even with (1) you end up with an additive function rather than
> multiplicative. In the case of SHA1 + MD5 the complexity should be:
>
>   m*2^(n/2) + 2^(m/2)
>
>   (128)*2^(160/2) + 2^(128/2)
>   = 128 * 2^80 + 2^64
>   = 2^7 * 2^80 + 2^64
>   = 2^87 + 2^64

This is considering the case of brute-force. If coliding SHA1 is
actually 2^87, you can consider it safe, period.

Now, if someone clever finds a way to colide SHA1 in n, log(n) or so,
then, one of the element in your sum becomes negligible, and the
important is to keep the other. So, having two hash functions might
not give you a 2^{enough}, but if the hash functions are sufficiently
different, the probability to have non-brute-force attack on both is
really smaller than the individual.

And another technical advantage of having two functions is that the
transition to a new function is made easier when one is considered
broken : if version N of your software considers hash1 and hash2
function, the day hash1 is broken, you can release version N+1
managing hash2 and hash3, and version N and N+1 have hash2 in common,
which is still considered secure at this point.

-- 
Matthieu



More information about the bazaar mailing list