----- Forwarded message from Sašo Kiselkov <[email protected]> -----
From: Sašo Kiselkov <[email protected]> Date: Tue, 12 Feb 2013 23:14:36 +0100 To: [email protected] CC: Nico Williams <[email protected]>, Richard Elling <[email protected]> Subject: Re: [zfs] Edon-R hashing and dedup User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 Reply-To: [email protected] On 02/12/2013 10:31 PM, Nico Williams wrote: > On Tue, Feb 12, 2013 at 12:34 PM, Garrett D'Amore > <[email protected]> wrote: >> I think security could be important here. A determined attacker with access >> to the file system (perhaps very indirectly) could cause devastating >> corruption if he could arrange for collisions against a key file or block on >> a dataset with dedup and no verify set. >> >> Admittedly the likelihood of a successful attack is low, but that isn't the >> same as saying that security is not a consideration for the ZFS hash >> function. > > That's why dedup requires a cryptographic hash. No, the cryptographic bit was chosen as a simple designator of "hash with collision resistance", since cryptographic security implies that. > Any SHA-3 candidate that was not rejected due to weaknesses discovered > in cryptanalysis is almost certainly good enough for dedup. I would contend that the priority for ZFS dedup is: 1) software speed 2) collision resistance 3) cryptographic security The last two are not the same. Other hashes I considered were: BLAKE2: 1) It's slower than Edon-R (considerably so, the best I managed to get was ~5 CPB). 2) The above result requires using SSE 4.1 or other advanced vector instructions, which is difficult to support in the kernel. This also means that performance will suffer significantly if these instructions aren't available (e.g. on older CPUs or non-x86 CPUs). 3) It's derived from BLAKE, one of the SHA-3 finalists, which should make it theoretically as safe (though it hasn't been subjected to cryptanalysis to make sure the implementors haven't made a mistake). Blue Midnight Wish: 1) It's somewhat slower than Edon-R (though not as slow as BLAKE2) 2) Has been subjected to SHA-3 cryptanalysis and currently no preimage attacks exist against it (and no practical attacks on the full version of the hash either). 3) Its implementation is pure C, like Edon-R (no SSE trickery required). Let's, however, not lose focus on what is really important. Edon-R has *not* been broken. 1st preimage at complexity 2^343 is at most a thinking pause, however, it is nowhere near being anything practical. We'd be using the hash truncated to 256-bits anyway, which makes an exhaustive search still much easier to perform. The reason SHA-3 discarded it is because SHA-3 has a much broader scope and is supposed to mandate a standard for hashing all sorts of data at all possible sensitivity levels. ZFS dedup has an extremely narrow scope and the nature of our data is much more constrained, meaning, even if some theoretical attack can be made remotely practical, it is still nowhere near to posing any problems for our particularly narrow-scoped application. Cheers, -- Saso ------------------------------------------- illumos-zfs Archives: https://www.listbox.com/member/archive/182191/=now RSS Feed: https://www.listbox.com/member/archive/rss/182191/22842876-6fe17e6f Modify Your Subscription: https://www.listbox.com/member/?member_id=22842876&id_secret=22842876-a25d3366 Powered by Listbox: http://www.listbox.com ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org";>leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
