ZFS and encryption

mpoleski

Cadet
Joined
Jun 16, 2019
Messages
5
There are basically two approaches to ZFS encryption:
  • LUKS/GELI hard drives (below ZFS)
  • ZFS native encytpion
LUKS is the way I'd go by default. But then I learned that raid0 is a bad idea (because ZFS loses direct access to hardware?). And quite recently about ZFS native encryption.


Let's start by tackling LUKS below ZFS. I imagine system where each hard drive is encrypted separately. Actual ZFS volumes are built on top of virtual devices.
Advantages:
  • LUKS is a pretty standard solution. Hopefully there was enough time to handle security issues inherent to any new crypto solution.
  • Because disks are encrypted directly, encryption of files stored in the logical volume build on top of it naturally parallelizes on physical disks layer.
Disadvantages:
  • ZFS no longer has direct access to the hardware. Is it a big deal? If one disk starts failing (for example has bad sectors) how is that going to look like for ZFS?

ZFS native encryption is an all-in-one solution. Has some additional abilities like scrubs without keys loaded at expense of disclosing more about data stored. I don't think these additional abilities have big value for me (I will always be able to load keys/ensure keys are loaded when scrub/other tasks are to be executed).
Advantages:
  • ZFS has direct access to hardware.
Disadvantages:
  • Relatively new crypto solutions. Can have (unknown) security vulnerabilities. Fixing them might require change of data format (as already had in the past).
  • What is the performance? In this model we probably don't have the parallelization opportunity (raw copy to another devices is possible, so keys are not tied to hard disks).

What is your look on this? How is raid0 issue related to LUKS below ZFS? Do you think that native encryption is safe/stable/efficient enough? Anything missing?
 

ovizii

Patron
Joined
Jun 30, 2014
Messages
435
I'm curious about performance. comparing ZFS with GELI encryption vs ZFS native encryption.

I removed the GELi encryption from a pool running on a freenas 11.x server to a Debian Buster Server with ZOL, now all my datasets are unencrypted. I created NEW encrypted datasets and am busy moving data from unencrypted to encrypted datasets and it looks like its very, very slow.

Admittedly this runs on a pretty old machine: HP ProLiant G7 MicroServer N54L with a AMD Turion II Neo N54L, 2x 2.20GHz processor.

It "feels" like it was faster when using GELI vs native encryption but I can't find any benchmarks. is it maybe lacking some instructions sets? http://www.cpu-world.com/CPUs/K10/AMD-Turion II Neo N54L - TEN54LSDV23GME.html
 

HolyK

Ninja Turtle
Moderator
Joined
May 26, 2011
Messages
653
One comment from my end

GELI is (whole) disk-level encryption and ZFS is build on top of that. So it is all or nothing. Changing (enabling/disabling) encryption requires moving data elsewhere, destroying and re-creating the pool, then moving data back. I am avoiding the "unofficial" way with re-silvering trick which is too dangerous i would say.
vs.
ZFS Native Encryption is on ZFS level. You can have some Datasets encrypted while others can be un-encrypted. Encryption is inherited so if dataset is encrypted all child datasets are encrypted as well. But you can have "Unencrytpted" and three "child" datasets where only one is encrypted.
Also you can encrypt/decrypt the data without destroying the whole pool (sort of). If you have un-encrypted dataset you can just create new encrypted one and move data via zfs send/recv then destroy the source. The same approach can be used for "disabling" the encryption (create un-encrypted, move data there, destroy the old). Only exception is if you have the root "dataset" with enabled encryption. In that case everything is forced to be encrypted.

And two questions as well:
- Can ZFS utilize AES-NI HW crypto instructions sets?
- Imagine i have "unencrypted" dataset, then i create an encrypted one and "copy" data there. After that i will delete/destroy the "unencrypted" one. How to ensure that the data are safely removed/rewritten and could not be recovered? Yea after some time and bunch of new data stored the blocks will get eventually overwritten by something else but there is no control about "when". In theory the data from deleted dataset could be recovered till that happen. I don't like that :/
 

ovizii

Patron
Joined
Jun 30, 2014
Messages
435
I am avoiding the "unofficial" way with re-silvering trick which is too dangerous i would say.
That is what I did, pulling the disks one by one, removing geli and resilvering. There is a very good how-to on this forum.

If you have un-encrypted dataset you can just create new encrypted one and move data via zfs send/recv then destroy the source.
That does not work right now. You cannot send from an unencrypted dataset and receive in an encrypted dataset. Not implemented yet. You can work around that by creating a dataset inside an encrypted dataset then you can receive but that is not what I want so I did a basic "mv unenc/* enc/ and am literally watching my data slowly flow from one dataset to the other. Hence my question about speed.
Imagine i have "unencrypted" dataset, then i create an encrypted one and "copy" data there. After that i will delete/destroy the "unencrypted" one. How to ensure that the data are safely removed/rewritten and could not be recovered? Yea after some time and bunch of new data stored the blocks will get eventually overwritten by something else but there is no control about "when". In theory the data from deleted dataset could be recovered till that happen. I don't like that :/
I totally agree with you on this one.
 
Top