Live data from Hacker News

Playing with ZFS encryption on Linux

rolando.cl

41–50 of 56 posts

Re: Playing with ZFS encryption on Linux

#41
post #40

I almost cannot wait for this. Native file system encryption will be so good, because it removes the ugly/inelegant layer of indirection with Geli or LUKS, and it allows stuff like encrypted ZFS send and receive. It allows you to switch on and off encryption dynamically. That will allow you to use services like rsync.net without having to place as much trust their internal security practices. It's great they're takin…

Uncertain that it enables encrypted send and receive. It very likely decrypts to get it into the send format, and then is reencrypted on the receive side. Those are separate file systems so it's not certain that they share, or even should share, the same encryption key.

Update: Ahh well it helps to whole article before posting. Both encrypted and decrypted send/receive are possible. But this also suggests multiple keys per pool, a key per file system I guess?

Re: Playing with ZFS encryption on Linux

#42

Does anyone know a good guide for getting set up with ZFS (particularly on Linux/Ubuntu)? The Ubuntu wiki basically just say "apt install zfs" and then links to a page that appears to be a brain dump of all the possible commands. Something with more coherence explanation of the relevant concepts would be really helpful.

Not explicitly Ubuntu, but with a little translation I think the Arch Linux ZFS wiki page would serve you well: https://wiki.archlinux.org/index.php/ZFS

Re: Playing with ZFS encryption on Linux

#43

A little more details on the crypto aspects: https://blog.heckel.xyz/2017/01/08/zfs-encryption-openzfs-zf... (This is my post. I hope it's okay to post this here.)

Have the design decisions been reviewed by a cryptographer yet? According to the presentation on youtube, it had not.

We are having trouble finding a volunteer.

Re: Playing with ZFS encryption on Linux

#44

Will this work the same way on FreeBSD/FreeNAS when this eventually lands? OT: one of the sed lines is hard to read sed -i 's/github.com\/zfsonlinux\/zfs.git/github.com\/tcaputi\/zfs.git/' PKGBUILD the OP might leverage that you can use other quoting characters, like sed -i 's,github.com/zfsonlinux/zfs.git,github.com/tcaputi/zfs.git,' PKGBUILD

Yes. The plan is for this tone the same across all OpenZFS platforms. How long it takes to be adopted by the others is another story though.

Re: Playing with ZFS encryption on Linux

#45
post #40

I almost cannot wait for this. Native file system encryption will be so good, because it removes the ugly/inelegant layer of indirection with Geli or LUKS, and it allows stuff like encrypted ZFS send and receive. It allows you to switch on and off encryption dynamically. That will allow you to use services like rsync.net without having to place as much trust their internal security practices. It's great they're takin…

It's a reasonable indirection, putting encryption into the file system is controversial, see NTFS for the pitfalls.

Re: Playing with ZFS encryption on Linux

#46
post #22

Does anyone know a good guide for getting set up with ZFS (particularly on Linux/Ubuntu)? The Ubuntu wiki basically just say "apt install zfs" and then links to a page that appears to be a brain dump of all the possible commands. Something with more coherence explanation of the relevant concepts would be really helpful.

I have documented the steps I had to take here https://janweitz.de/article/creating-a-zfs-zroot-raid-10-on-... Be aware: Uefi did not work for me in VirtualBox with ZFS. Booting with UEFI, ZFS and RAIDz works, but I did not figure out how to install the UEFI grub-boot on all RAIDz drives. Therefore, if the one and only drive with the boot partition fails, I have to rely on an USB-stick as a backup-plan for the bootlo…

Maybe I had a better luck, for me, UEFI boot with ZFS in Virtualbox did work. I've used CentOS though.

Multiple UEFI boot partition are possible, but just like you note in your article, they have to be outside the ZFS pool. All of them. Then you set order for each one using efibootmgr. For each, you will get a separate entry in UEFI boot manager.

It is not necessary to install grub2 after rebooting into ZFS root. It is perfectly fine to run grub2-install in chroot from your temporary installation.

Re: Playing with ZFS encryption on Linux

#47
post #40

I almost cannot wait for this. Native file system encryption will be so good, because it removes the ugly/inelegant layer of indirection with Geli or LUKS, and it allows stuff like encrypted ZFS send and receive. It allows you to switch on and off encryption dynamically. That will allow you to use services like rsync.net without having to place as much trust their internal security practices. It's great they're takin…

The nice thing about LUKS for the end-user, however, is that it's well-supported in most Linux distros these days, and the end-user can turn it on within the graphical installer literally by checking a box, "Encrypt my Hard-drive."

When ZFS gets there, I will probably switch to it. Until then, however, I find manually partitioning volumes on the command-line to be terrifying, and I imagine I'm not alone.

Re: Playing with ZFS encryption on Linux

#48
post #43

Earlier quoted context omitted.

Have the design decisions been reviewed by a cryptographer yet? According to the presentation on youtube, it had not.

We are having trouble finding a volunteer.

I'm not a cryptographer, but for your dedup version, you might want to consider using SIV mode [1,2]. It provides a well known, already vetted deterministic authenticated encryption, so you don't have to build your own from HMAC etc and then get it vetted.

[1] http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/propose...

[2] https://tools.ietf.org/html/rfc5297

Re: Playing with ZFS encryption on Linux

#50
post #43

Earlier quoted context omitted.

Have the design decisions been reviewed by a cryptographer yet? According to the presentation on youtube, it had not.

We are having trouble finding a volunteer.

Would the Core Infrastructure Initiative be willing to sponsor a cryptographer to review it?

Getting this right would make it a lot easier to have faith in encrypted backups. Right now, you have to trust that each network backup product like bacula is doing it right.

I just randomly picked bacula and then looked up what they are doing. They're using OpenSSL with AES-CBC. I don't think anyone would recommend that.

As a start, it would be nice if Datto could document the design decisions. For instance, AES-CCM is a bit of a strange default and it's not explained anywhere. I see Solaris chose AES-128-CCM and maybe that influenced why OpenZFS is using AES-256-CCM. I haven't found a cryptographer in favor of CCM over GCM. For instance, Matthew Green doesn't appear to like it over GCM.

https://blog.cryptographyengineering.com/2012/05/19/how-to-c...

According to Crypto++'s benchmark, AES-GCM is 2,448 MB/s and AES-CCM is 710 MB/s. Does that match your experience with OpenZFS?

https://www.cryptopp.com/benchmarks.html

Given that GCM IV reuse is catastrophic and one of the main use cases for this is backups to potentially untrusted sources, I'm curious if AES-GCM-SIV would be a more conservative choice.

https://www.imperialviolet.org/2017/05/14/aesgcmsiv.html

Post reply on HN