[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freebsd-hackers
Subject:    Re: ZFS encryption and loader
From:       Eric McCorkle <eric () metricspace ! net>
Date:       2020-09-16 1:58:22
Message-ID: a5f7be27-fa1f-b237-80c5-c1f802ff0210 () metricspace ! net
[Download RAW message or body]

[Attachment #2 (multipart/mixed)]


On 9/12/20 9:37 PM, Eugene Grosbein wrote:
> 13.09.2020 5:46, Eric McCorkle wrote:
> 
>> I'm thinking of migrating to ZFS encryption from GELI in the near future.
>>
>> Does anyone know offhand what the state of support for ZFS encryption in
>> loader looks like, and if there's support for passing keys to the kernel
>> for boot-time loading?  (I can look at adding these if they're missing)
> 
> Recently I've learned from one of ZoL maintainers that native
> ZFS encryption is not so comprehensive as GELI.
> 
> I've been told that native ZFS encryption was initially designed for one specific task:
> being able to receive encrypted customer data (backups), verify its integrity without decryption,
> store and then receive incremental backups later. Therefore, not all data is hidden with encryption,
> for example, dataset names and some other metadata are not.
> 
I've looked into this prior, and you're right.  The metadata that
remains unencrypted shouldn't be a security risk, unless you're leaking
info through your dataset names or something.  I don't know enough about
ZFS to know whether encryption for that stuff could be added later.

One big advantage you get is per-block single-use keys and tight
integration of AEAD.  I would regard this as more trustworthy than
repeatedly encrypting with the same key.  It also opens the door to some
interesting proactive security features.


["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]