Date: Fri, 6 Nov 2020 15:53:52 -0800 From: John-Mark Gurney <jmg@funkthat.com> To: Eric McCorkle <eric@metricspace.net> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: Mounting encrypted ZFS datasets/GELI for users? Message-ID: <20201106235352.GE31099@funkthat.com> In-Reply-To: <794d789d-4056-4152-e7f6-bf9d10d42518@metricspace.net> References: <8d467e98-237f-c6a2-72de-94c0195ec964@metricspace.net> <20201026221215.GB31099@funkthat.com> <794d789d-4056-4152-e7f6-bf9d10d42518@metricspace.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Eric McCorkle wrote this message on Sat, Oct 31, 2020 at 15:48 -0400:
> On 10/26/20 6:12 PM, John-Mark Gurney wrote:
> > Eric McCorkle wrote this message on Mon, Oct 05, 2020 at 09:45 -0400:
> >> I'm presently looking into options presented by ZFS encryption. One
> >> idea I had was something like this (I'm going to go with ZFS for now,
> >> but you could presumably do something like this with GELI, with more
> >> effort).
> >
> > I'd still recommend using GELI. Even w/ ZFS's native encryption, the
> > metadata for ZFS remains unencrypted, and able to be munged. If you
> > geli w/ ZFS and a strong checksum, like sha512/256, I believe that this
> > is the equiavlent to authenticated encryption, ala geli's authenticated
> > mode, but with significantly less overhead...
>
> Something to note is that GELI's authenticated mode changes the block
> size, because it uses the last bytes in each block to hold the MAC.
> This is likely to have consequences for performance.
Which is why I don't use it, and use GELI's unauthenticated mode (default)
w/ ZFS strong hashes...
> However, this also does suggest a ZFS feature that would create a MAC
> code for the root block of the filesystem (I am less familiar with the
> ZFS on-disk format, but as it's a write-once format with MAC information
> stored at each block pointer, this would have the effect of protecting
> the entire filesystem from offline tampering.
Yes, that is one of the reasons I'm not interested in ZFS native
encryption is that it only protects datasets, but the rest of the
metadata is not protected... Adding MACs all of the ZFS metadata
blocks would be good for native ZFS encryption, but short of encrypting
ALL the ZFS metadata, it doesn't satisfy my needs...
The reason I'm fine w/ GELI + sha512/256 is the way AES blocks
work..
GELI w/ AES-XTS, each 16byte chunk is encrypted w/ a stream cipher,
so there is zero overlap between chunks. W/ sha512/256, the hash is
32bytes. So, an attacker would have to corrupt TWO 16 byte blocks of
data wich exactly the correct data, to get ZFS to trust the checksum.
If an attacker can do that, they very likely have the encryption key,
so it's game over anyways.
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20201106235352.GE31099>