Support LUKS / cryptsetup compatible slot management of the encryption keys

[xnox]

Describe the feature would like to see added to OpenZFS

I would like to have multiple tokens to unlock encrypted ZFS storage. Ideally with ability to have static tokens, tokens sealed to TPM, remote unlock, etc. On the same parity as cryptsetup / LUKS header offers. Such that they in turn are used to unlock the native master zfs key.

How will this feature improve OpenZFS?

Having native support for multiple LUKS compatible tokens, will ease management, recovery, deployment of zfs systmes, and aid migrating from previously used solutions such as LUKS+LVM+EXT4.

Additional context

When attempting to implement encrypted ZFS on Ubuntu Desktop, the existing support for backup recovery key and escrow services resulted in a design choice of creating LUKS+EXT4 partition that contains a passphrase file which is then used to unloack the encrypted zfs pool. A better, native support for something like this would be nice.

For example, to allow encapsulating luks header in the ZFS ondisk format somehow, i.e. as a special unecrypted zvol that contains LUKS tokens for the zfs master key would be ideal.

[amano-kenji]

It turns out that I needed only one key slot.

With keyformat=passphrase and keylocation=file:///path/to/keyfile, even if I lose the keyfile, I can reconstruct it if I remember the passphrase. I can just write the passphrase in keyfile.

I use the same passphrase for root filesystem and other filesystems. Before I knew this, I thought I needed one key slot for a keyfile and another key slot for a passphrase.

Is a passphrase keyfile enough for your use case?

[xnox]

Is a passphrase keyfile enough for your use case?

No, not at all. Multiple slots are needed for the same/single volume, to allow different users and roles to decrypt the volume; for backup, recovery, admin, user access.

[amano-kenji]

That's a legitimate use case, but encryption is bad at multi-user access. You are going to need zfs on luks for a long time.

[xnox]

That's a legitimate use case, but encryption is bad at multi-user access. You are going to need zfs on luks for a long time.

Yes, that's why in part github.com/canonical/zsys exists with using keyfile, on LUKS, with keyslots, as a poor solution.

However having LUKS2 compatible keyslot format, and zkey derivation would help a lot, as part of the pool header itself.

Even if zkey commands are actually just a wrapper around tiny LUKS header on an unencrypted zvol of the zfs pool. (Or in any other way - a very large zpool property?!)