[zfs] [Review] 4185 New hash algorithm support

[Tim Cook]

On Sat, Oct 19, 2013 at 6:26 AM, Pawel Jakub Dawidek <pjd at freebsd.org>wrote:

> On Mon, Oct 07, 2013 at 11:18:21PM +0100, Saso Kiselkov wrote:
> > On 10/7/13 10:17 PM, Zooko Wilcox-OHearn wrote:
> > > So, before I go on with my pitch for why you should consider BLAKE2,
> > > first please clarify for me whether ZFS really needs a
> > > collision-resistant hash function, or whether it needs only a MAC. I
> > > had thought until now that ZFS doesn't need a collision-resistant hash
> > > unless dedup is turned on, and that if dedup is turned on it needs a
> > > collision-resistant hash.
> >
> > The reason is purely for dedup and pretty much nothing else. As such, we
> > only need a hash with a good pseudo-random output distribution and
> > collision resistance. We don't specifically need it to be super-secure.
> > The salted hashing support I added was simply to silence the endless
> > stream of wild hypotheticals on security.
>
> Just FYI, Richard Yao just proposed providing VM images with existing
> ZFS pool also for production use. This is great idea, but also a nice
> proof why making assumptions on how exactly a general purpose software
> will be used is bad. In this case your salted hashing is pointless as
> everyone knows about the salt in those images. And we are back to square
> one.
>
> Saso, there are countless examples where so called hypothetical security
> bugs turned out to be exploitable in practise. Which is especially true
> for general purpose software that we have no control over how it is
> being used.
>
> As Zooko mentioned cryptoanalysis of the Edon-R algorithm stopped at the
> point where we know it is not cryptographically secure and this is
> unlikely we will see any further work in the subject, which in my eyes
> is even worse, as we don't know how bad is it.
>
> To sum up. Even if the OpenZFS community will agree to integrate Edon-R,
> I'll strongly oppose having it in FreeBSD. In my opinion it is just
> asking for trouble. I still like your change very much and would love to
> see new, cryptographically secure hash algorithms for dedup in ZFS.
> Currently there is no alternative, which is bad for security too.
>
> --
> Pawel Jakub Dawidek                       http://www.wheelsystems.com
> FreeBSD committer                         http://www.FreeBSD.org
> Am I Evil? Yes, I Am!                     http://mobter.com
>
>
>
So as I have asked previously, can you point to any working exploit of any
of the commercially available deduplication stacks?  None of them are
cryptographically secure.  All of them are used in extremely high value
targets including top secret government installations.  I would assume that
almost a decade on there is working code out there if the exploits are
anything beyond hypothetical.  While I applaud your diligence, it seems
beyond silly to me to hamstring people's options because you PERSONALLY
wouldn't want to use that as an option.  If I as a user understand and am
willing to accept the risks associated in exchange for something
approaching usable from a performance perspective, you're telling me I
shouldn't get that option because you are worried about a theoretical
exploit.  That's an awfully slippery slope to start heading down.  Where
does that stop?  Are you going to recommend BSD also stop supporting any
system that boots off of PCBIOS which has been proven to be exploitable in
the field?   Are we going to remove md5sum from BSD because that's
exploitable?

If you want to recommend they not have it as the default, great.  But
recommending it not be included at all because you don't feel comfortable
with it seems like a GREAT disservice to the community.  I thought this
horse had already been beaten to death but I guess not.

--Tim



-------------------------------------------
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/html
Size: 6313 bytes
Desc: not available
URL: <http://lists.cpunks.org/pipermail/cypherpunks/attachments/20131019/69736b1c/attachment-0001.txt>