On 4/20/2011 1:18 AM, Luc Perthuis wrote:
Hi all,
I'm specially interested on finding a way to uniquely identify rather
small data chunks (less than or equal to 128*1024 bytes in size) without
using a byte per byte compare.
Is there any theoretical proof for a "good" selection of 2 HASH
(computing the results of two different algorithms on the same data)
that would annihilate the collision risk ?
Simply use a hash for which the probability of a collision (either
accidental or malicious) is at least one order of magnitude lower than
the probability of your most probable failure mode. IMO, SHA-512 has
this characteristic, unless you plan on shielding your hardware from
cosmic rays.
There is no advantage to using two different algorithms and two huge
disadvantages. First, the computation time will be greater. Second, the
vulnerability risk is likely greater. It is expected, for example, to be
harder to break a single 512-bit hash than to break two 256-bit hashes
concurrently. The probability of an accidental collision should be the
same -- so why do more work?
NB: I've mentioned MD5 and SHA-1 in the subject, as they are the most
used nowadays, but if this association doesn't fit the need whereas
another does, that would be interesting anyway ;-)
If you're willing to go to 288-bits, why not just use 512-bit SHA and
truncate to 288 bits? That way, you don't have the known weaknesses of
MD5 dragging you down and each bit 'pays its way'.
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
