On Sat, Oct 19, 2013 at 6:26 AM, Pawel Jakub Dawidek
   <[1]pjd@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
     [2]http://www.wheelsystems.com
     FreeBSD committer                         [3]http://www.FreeBSD.org
     Am I Evil? Yes, I Am!                     [4]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 | [5]Archives
   [6][40414441.jpg?uri=aHR0cHM6Ly93d3cubGlzdGJveC5jb20vaW1hZ2VzL2ZlZWQtaW
   Nvbi0xMHgxMC5qcGc] | [7]Modify Your Subscription [8]Powered by Listbox

References

   1. mailto:pjd@freebsd.org
   2. http://www.wheelsystems.com/
   3. http://www.FreeBSD.org/
   4. http://mobter.com/
   5. https://www.listbox.com/member/archive/182191/=now
   6. https://www.listbox.com/member/archive/rss/182191/22842876-6fe17e6f
   7. https://www.listbox.com/member/?member_id=22842876&id_secret=22842876-a25d3366
   8. http://www.listbox.com/