Zfs: [Feature Request] encrypted send of unencrypted datasets

[c0d3z3r0]

It would be great to be able to locally encrypt plaintext datasets on the sending side, so that the receiving side does not have to know the secrets. This is mainly useful for sending backups from LUKS-encrypted systems (ZFS on LUKS) to lesser-trusted systems.

This feature was requested before in #7966 but is closed for unknown reasons (not even the "closed" message is there and posts seem to be missing o.O).

[johnnyjacq16]

How to send an encrypted dataset to a non-enecryped dataset, recursively?

[ahrens]

@johnnyjacq16 Unless the --raw/-w flag is specified, zfs send will send decrypted (plaintext) data. So you can use zfs send -R ....
(Side note, this is kind of the opposite of the feature that this Issue is requesting.)

[kithrup]

Pipe the output of zfs send through openssl. There is no particular way for zfs send, itself, to encrypt an unencrypted dataset (although it would be possible, I suppose, to have the _output_ of zfs send be encrypted, but this would essentially be the same as piping through openssl).

[misterbigstuff]

well, no, because piping it into openssl doesn't make it an encrypted filesystem on the receiving end. it's just an encrypted file, that will decrypt into a plaintext filesystem.

the user is asking for a way to make an encrypted ZFS dataset from an unencrypted one on-the-fly on the sending side, so that the receiver is blind to it.

it would be more like zfs send -D that deduplicates streams on-the-fly as they're sent.

i imagine this wouldn't be very maintainable long term, and probably not very useful. if you encrypt data as it sends, do you provide the key every time so the incrementals work? is it just for a full send and not supported by incrementals?

it seems like a mess. maybe just abandon LUKS and use native encryption the whole way through.

[c0d3z3r0]

@kithrup Well, you got it. "There is no particular way for zfs send, itself, to encrypt an unencrypted dataset" <- Thus, this feature request. So what is unclear?

@misterbigstuff

it would be more like zfs send -D

Exactly!

maybe just abandon LUKS and use native encryption the whole way through

This is not a solution, when FDE is explicitely wanted. Correct me if I'm wrong, but AFAICT ZFS does not encrypt metadata and does not protect from modification (adding, removing volumes) but just encrypts volumes.

if you encrypt data as it sends, do you provide the key every time so the incrementals work

That would be a requirement, yes. A wrong key would have to be rejected.

it seems like a mess

If designed carefully, it's not a mess at all. Just because it is impossible to fulfill any wishable use-case, it's not a mess. There are always limitations.

[misterbigstuff]

well, then zfs send -D is still a good example because of its complexity, it was removed from the codebase.

you can use FDE under ZFS encryption with the associated performance penalty, for the benefit of a much simpler system.

[c0d3z3r0]

@misterbigstuff I don't get what you mean by "FDE under ZFS encryption"

Edit: got it... still not really awake today ;) Yeah, ofc that would be possible but adds the mentioned performance penalty

[misterbigstuff]

well encrypting things on the fly isn't going to be free from a performance standpoint either.. it's definitely not free from a code maintenance perspective.

[c0d3z3r0]

Yes, that is right. At least it's better to have the performance "problem" only when doing the send instead of at runtime. irt maintenance I can't tell tbh. I had a short look on the -D code but I wasn't involved, so I don't know

[c0d3z3r0]

@johnnyjacq16 why are you hijacking this feature request for user support?

[InsanePrawn]

From my understanding of the openzfs crypto scheme, there is a UX problem with this:
Unless this issue is explicitly addressed in an implementation, I suspect the send stream would generate a new random child key from [cryptographicaly] related to an encryptionroot the user specifies via CLI, right?
The 'random' part of that sentence would by default mean that sending a filesystem or snapshot twice that way (two different zfs send invocations with the exact same args) results in two different, incompatible streams. This is fine for a one-time send only but breaks all kinds of incremental, clonery, etc.
Not sure how the UI to address this would look but it doesn't sound pretty.
(I just realised it might also just create a new encryptionroot, but the same random key problem arises)

[edit: wrong and unrelated stuff removed]

Edit: Ah, your OP mentions it:

It would be great to be able to _locally encrypt_ plaintext datasets _on the sending side_, so that the receiving side does not have to know the secrets. This is mainly useful for sending backups from LUKS-encrypted systems (ZFS on LUKS) to lesser-trusted systems.

So I assume you'll want to incrementally send your backup dataset multiple times. How/where should ZFS store the encryption keys on the sending side?

BTW:

This feature was requested before in #7966 but is closed for unknown reasons (not even the "closed" message is there and posts seem to be missing o.O).

This is a symptom of a user who requested Github to delete all their posts (apparently/allegedly after getting suspended), the 404ing user mention and dialogues turned monologues are a good hint :)

[johnnyjacq16]

@ahrens @c0d3z3r0 I have now moved my issue case number #10507