John Williams wrote: > On Mon, Dec 1, 2014 at 12:35 PM, Austin S Hemmelgarn > <ahferro...@gmail.com> wrote: >> My only reasoning is that with this set of hashes (crc32c, adler32, and >> md5), the statistical likely-hood of running into a hash collision with >> more than one of them at a time is infinitesimally small compared to the >> likely-hood of any one of them having a collision (or even compared to >> something ridiculous like the probability of being killed by a meteor >> strike), and the combination is faster on most systems that I have tried >> than many 256-bit crypto hashes. > > I have not seen any evidence that combining hashes like that actually > reduces the chances of collision, but if we assume it does, then > again, the non-crypto hashes would be faster. For example, 128-bit > Spooky2 combined with 128-bit CityHash would produce a 256-bit hash > and would be faster than MD5 + whatever.
It has no real benefit, but _why_ depends on what your model is. There's a saying that engineers worry about stochastic failure; security professionals have to worry about malicious failure. If your only concern is stochastic failure (random bitflips, etc), then the chances of collision with 128-bit CityHash or MurmurHash or SipHash or what- have-you are already so small that every single component in your laptop dying simultaneously is more likely. Adding another hash is thus just a waste of cycles. If your concern is malicious failure (in-band deduplication attack or similar, ignoring for now that btrfs actually compares the extent data as well IIRC), then it's well-known in the cryptographic community that the concatenation of multiple hashes is as strong as the strongest hash, _but no stronger_ [1]. Since the strongest cipher in the above list is either a non-cryptographic hash or MD5, which is known-weak to the point of there being numerous toy programs finding collisions for arbitrary data, it would not be worth much. The only place this might be of use is if you used N strong/unbroken hashes, in order to hedge against up to N-1 of them being broken. However, the gain of that is (again) infinetismal, and the performance cost quite large indeed. [1] http://eprint.iacr.org/2008/075 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
