4 ms·
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
by DCKing 9y ago
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 taking their time, but I've been looking forward to a stable release since its announcement almost a year ago :)
- cmurf 9y agoUncertain 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?
- tcaputi 9y agoYes, there are per filesystem / zvol keys and the raw encrypted data is sent over the wire along with the encrypted keys.
- rexicus 9y agoIt's a reasonable indirection, putting encryption into the file system is controversial, see NTFS for the pitfalls.
- AdmiralAsshat 9y agoThe 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.