On Wed, Nov 26, 2014 at 08:58:50AM -0500, Austin S Hemmelgarn wrote: > On 2014-11-26 08:38, Brendan Hide wrote: > > On 2014/11/25 18:47, David Sterba wrote: > >> We could provide an interface for external applications that would make > >> use of the strong checksums. Eg. external dedup, integrity db. The > >> benefit here is that the checksum is always up to date, so there's no > >> need to compute the checksums again. At the obvious cost. > > > > I can imagine some use-cases where you might even want more than one > > algorithm to be used and stored. Not sure if that makes me a madman, > > though. ;) > > > Not crazy at all, I would love to have the ability to store multiple > different weak but fast hash values. For example, on my laptop, it is > actually faster to compute crc32c, adler32, and md5 hashes together than > it is to compute pretty much any 256-bit hash I've tried.
Well, this is doable :) there's space for 256 bits in general, the order of checksum bytes in one "checksum word" would be given by fixed order the algorighms are defined. The code complexity would increase, but not that much I think. > This then brings up the issue of what to do when we try to mount such a > fs on a system that doesn't support some or all of the hashes used. I see two modes: first fail if all not present, or relaxed by a mount option to accept at least one. But let's keep this open, I'm not yet convinced that combining more weak algos makes sense from the crypto POV. If this should protect against random bitflips, would one fast-but-weak be comparable to a combination? Or other expectations. -- 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