On Mon, Dec 01, 2014 at 03:23:03PM -0800, Alex Elsayed wrote: > > 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.
So as far as speed is preferred over strength, it does not matter much which algorithm we choose and combining more together does not bring a significant benefit. Crc32 is weak but has served well over the years, the improvement to anything 128bit-based should be obvious. > 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]. In-band dedup uses sha anyway, the block checksums are only used for verification. > 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. Thanks for you valuable input! -- 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
