With legacy you could enter a password which actually just encrypted the key file I guess, .. not sure if this works the same with the new encryption. Since it doesn't even hide the names of the zfs datasets.
It's a completely different method of encrypting your data. You can look at it from a different angle if it helps illustrate it better:
- GELI (legacy) encrypts the underlying partitions. These partitions are decrypted, which are then combined into vdevs, which then are part of your new (or imported) pool. If you never decrypt the partitions, you cannot continue, nor is there any available information of your pool, datasets, snapshots, metadata, structure, etc. Your ZFS pool and (datasets) running on top of GELI is (for all intents and purposes) non-encrypted. It is the lower level where encryption takes place. This is equivalent in the Linux world of encrypting a partition with dm-crypt/LUKS, and then creating an EXT4 file-system on top of this currently unlocked container. The EXT4 file-system is not encrypting anything; LUKS is. Just like in FreeNAS 11.3 and earlier, ZFS is not encrypting anything; GELI is.
- Native ZFS encryption happens on a per-dataset level. The underlying partitions are not encrypted. This means you're not limited to "all-or-nothing" as you would be with GELI. You don't need to encrypt all datasets, and technically the "pool" is not encrypted (even if you do encrypt the top-level "root" dataset, you can still create new child datasets without encryption.) A bit old, yet still relevant, I jotted down an overview of what is hidden from outsiders when your system is powered off. The reason much is visible with native ZFS encryption is that metadata is needed to be able to create snapshots, send/recv replications, run scrubs, etc, even while the dataset is "locked". (It's quite neat and gives you more flexibility).
But the pool needs to be encrypted. And the key/password can't stay on the system.
Edit: the key can stay on the system as long as it's encrypted of course.
If you use a "Key" rather than "Passphrase", it generates a random 64-character string. This is kept on the boot device so that the datasets automatically unlock upon reboot. (It can be exported as a .json file when you "Export" your dataset keys.) At any time you can change a dataset's encryption property from "Key" to "Passphrase". (Such as when you create a pool and select "Encryption", all it is doing is encrypting the root dataset, and defautling to a "Key". You can change this to a passphrase immediately aftwards.) If you use a passphrase, nothing is stored on the boot drive, nor will the dataset unlock automatically. It's up to you to memorize the passphrase. Regardless of which method you choose, you can always switch at any time. Unlike LUKS, it's "one or the other"; you can't choose
both for the same dataset. The 64-character string or the password is used to encrypt/decrypt the master key, as you guessed earlier. If you export a pool, however, then the keyfile is removed from the boot device, and you must re-upload it when you try to re-import the pool. If you don't, then it will still import your pool, but all your datasets will be "locked" and the data inaccessible until you upload the keyfile or manually enter the 64-character string.
But the pool needs to be encrypted.
Just remember that the entire "pool" is not encrypted. If you encrypt the "root" dataset, then by default all new child datasets created underneath will
inherit the encryption properties of the root/parent dataset(s). You can choose to be as hybrid as you want, nesting encrypted datasets underneath non-encrypted ones, and vice versa. Up to you!
