I am running geli on my FreeBSD home server with a Raidz1 setup.
-
I am running geli on my FreeBSD home server with a Raidz1 setup. I updated this server from 13 to 14 and 14 to 15. It seems like even in 15, full disk encryption with geli is the only encryption setup supported by the installer.
Since FreeBSD 15 supports ZFS encryption, I was wondering whether it’s worth to take the manual effort to reinstall and to configure ZFS encryption. What are your thoughts on this?
-
undefined stefano@mastodon.bsd.cafe shared this topic
-
I am running geli on my FreeBSD home server with a Raidz1 setup. I updated this server from 13 to 14 and 14 to 15. It seems like even in 15, full disk encryption with geli is the only encryption setup supported by the installer.
Since FreeBSD 15 supports ZFS encryption, I was wondering whether it’s worth to take the manual effort to reinstall and to configure ZFS encryption. What are your thoughts on this?
@NebulaTide It depends. If you want to encrypt just specific datasets, it makes sense. But if you want to encrypt the entire disk, I'd still use GELI.
-
I am running geli on my FreeBSD home server with a Raidz1 setup. I updated this server from 13 to 14 and 14 to 15. It seems like even in 15, full disk encryption with geli is the only encryption setup supported by the installer.
Since FreeBSD 15 supports ZFS encryption, I was wondering whether it’s worth to take the manual effort to reinstall and to configure ZFS encryption. What are your thoughts on this?
@NebulaTide Disk encryption is one of those things where a simple mistake with a new tool can cost you the whole system and all of its data. It would take a *really* good reason to get me to risk moving something which already exists.
There is unlikely to be much performance difference or security difference, so I would just stay with what you know works.
-
I am running geli on my FreeBSD home server with a Raidz1 setup. I updated this server from 13 to 14 and 14 to 15. It seems like even in 15, full disk encryption with geli is the only encryption setup supported by the installer.
Since FreeBSD 15 supports ZFS encryption, I was wondering whether it’s worth to take the manual effort to reinstall and to configure ZFS encryption. What are your thoughts on this?
@NebulaTide what’s the threat model? If all you care about is privacy of your data, ZFS encryption may be sufficient. If you care about privacy of things like dataset names, how often you create snapshots, properties and their values, ordering of writes to various datasets, etc., then you want full disk encryption. Perhaps your threat model requires both types of encryption for the most privacy and compartmentalization.
This has nothing to do with FreeBSD, it is common to ZFS on all platforms.
-
@NebulaTide Disk encryption is one of those things where a simple mistake with a new tool can cost you the whole system and all of its data. It would take a *really* good reason to get me to risk moving something which already exists.
There is unlikely to be much performance difference or security difference, so I would just stay with what you know works.
@bob_zim @NebulaTide I am a musician and am interested in encryption. When Apple first introduced FileVault I encrypted my whole disk, this was maybe 20 years ago. There was a weird bug in the FileVault that I triggered somehow. Upon a reboot, it refused my passphrase which I had written down on paper next to the computer. I lost all the data. I even took the PowerMac to the Genie Bar and they pretty much laughed and said nothing can be done. I hate disk encryption now.
-
@NebulaTide It depends. If you want to encrypt just specific datasets, it makes sense. But if you want to encrypt the entire disk, I'd still use GELI.
@stefano The big advantage I see is that you can boot headless and login via ssh while you’re stuck in the console with geli.
Tbh. there is no real thread model, and the data is only secure and encrypted when the server is shut down, so it doesn’t protect a running system. Nevertheless I am a fan of encryption and want to avoid storing unencrypted data whenever possible.