Can I zfs send encrypted incremental snapshots to a remote server and have them merged without ever having the remote server decrypt anything? That would be awesome to backup to an untrusted remote computer.
Yes.
Playing with ZFS encryption on Linux
31–40 of 56 posts
Re: Playing with ZFS encryption on Linux
#3264 bytes seems like an arbitrarily short limit for passphrases; it's going to be hashed at some point anyway (preferably with a decent KDF designed for the purpose) and 64 bytes is nowhere near long enough for natural English language text to be used to derive 32 bytes of entropy (estimates of English language text are ~1.5bits of entropy per character).
At the risk of invoking Cunningham's Law, nobody uses passphrases anywhere near 64 bytes that he / she has to memorize. And if you're using a password manager, just use the raw or hex key option. 32 bytes => 64 hex digits, which is probably not a coincidence. :-)
Er, of course it's not a coincidence; hex is base 16, so it takes 4 bits to represent each digit, which is half a byte. That is, hex always is 2 digits per byte.
Or did I miss your point?
Re: Playing with ZFS encryption on Linux
#33Will 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
FreeNAS has supported zfs encryption for a long while, unless I misunderstand you. Unless its not actually zfs encryption but something else?
It's only supported encryption in the same way Linux does: by doing a lower-level block device encryption. There's a lot of disadvantages to it, and native ZFS dataset encryption would be nicer.
Re: Playing with ZFS encryption on Linux
#3464 bytes seems like an arbitrarily short limit for passphrases; it's going to be hashed at some point anyway (preferably with a decent KDF designed for the purpose) and 64 bytes is nowhere near long enough for natural English language text to be used to derive 32 bytes of entropy (estimates of English language text are ~1.5bits of entropy per character).
At the risk of invoking Cunningham's Law, nobody uses passphrases anywhere near 64 bytes that he / she has to memorize. And if you're using a password manager, just use the raw or hex key option. 32 bytes => 64 hex digits, which is probably not a coincidence. :-)
> At the risk of invoking Cunningham's Law, nobody uses passphrases anywhere near 64 bytes that he / she has to memorize.
http://52.24.230.241/bc/password_generation.php
This produces memorable passphrases pretty close to that limit, as described in http://www-scf.usc.edu/~mghazvin/papers/marjan15.pdf
Re: Playing with ZFS encryption on Linux
#35Can I zfs send encrypted incremental snapshots to a remote server and have them merged without ever having the remote server decrypt anything? That would be awesome to backup to an untrusted remote computer.
Yes.
Without having read anything of the implementation.. That is little short of astounding.
Re: Playing with ZFS encryption on Linux
#36Earlier quoted context omitted.
Just the crypto primitives are from Illinois iirc, the actual scheme is fairly new.
Didn't Oracle ZFS have encryption for some time now? (Was that after closing Solaris?)
Yes and they have a poor implementation for encryption at that. Pawel who did the port of zfs to FreeBSD did not like how they implemented it. As far as zfs goes oracle will be the odd man out compatibility wise with the rest of the platforms supporting zfs and the openzfs encryption scheme.
Re: Playing with ZFS encryption on Linux
#37Can I zfs send encrypted incremental snapshots to a remote server and have them merged without ever having the remote server decrypt anything? That would be awesome to backup to an untrusted remote computer.
yes, it's at the end of the post, with a few cases of how recv and send work.
Re: Playing with ZFS encryption on Linux
#38Will 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
FreeNAS has supported zfs encryption for a long while, unless I misunderstand you. Unless its not actually zfs encryption but something else?
Free(BSD|NAS) so far create a "normal" ZFS on top of an encrypted block device, produced via the cryptographic GEOM provider geli ( https://www.freebsd.org/cgi/man.cgi?geli(8) )
This instead is ZFS doing the actual encryption on a normal block device.
Re: Playing with ZFS encryption on Linux
#39Does 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.
https://gist.github.com/xenophonf/2e2d1a1550b0fb8dae98
That's for Ubuntu 14, but it's basically the same process for Ubuntu 16. Neither installer supports root on ZFS, so you have to install Ubuntu to a flash drive, create the ZFS pool from the live environment, and then copy the contents of the flash drive onto the ZFS pool.
Just ignore the bits about dual-booting Mac OS X.
Re: Playing with ZFS encryption on Linux
#40I 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 taking their time, but I've been looking forward to a stable release since its announcement almost a year ago :)