[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).

[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).

[bghira]

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.

[bghira]

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

[bghira]

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

[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 :)

[CySlider]

I would second this request. As I am also in the same situation right now. I want an offsite backup on an untrusted location and can't shift around my datasets as they are too big. Even if I would be willing to accept the double performance hit of LUKS + ZFS enc.

Can't the "how to store the keys" be solved by maybe also specifying a seed for this use case?

[csoutreach]

I also need this feature.
In terms of implementation how about having someway of creating a 'dummy pool/dataset'; with the metadata for the pool/dataset stored in file -- this metadata would include the encryption options (same as normal pool).

To avoid polluting the existing tools, a new tool e.g. zfspipe could be created. e.g.

So for example:
initially, create a 'dummy' dataset in a dummypool with metadata stored in dummy_pool_meta_store.file

zfspipe create -f dummy_pool_meta_store.file -o encryption=aes-128-ccm -o keysource=raw dummypool/dataset

(with the appropriate selection of the usual creation options from zfs create)

then, anytime the unencrypted data needs to be sent encrypted:

zfs send realpool/data | zfspipe pipe dummypool/dataset -f dummy_pool_meta_store.file | zfs recv newpool/data

In terms of implementation, zfspipe would take then stream, receive it as recv would, (and so add encryption) but instead of writing it out to real blocks, it would repackage it into another send stream.

Initial thoughts with regard to maintaining it; main question;

• would it be easy to receive a stream into this special dummy pool that isn't persistent in the system
• how easy is it for this dummy pool to have a different storage backend, and
• could this storage backend loopback into using the code to serialize the blocks, without writing to any persistent storage.

I've not looked in full details of the implementation as to how feasible this is, so looking for feedback from someone who knows the codebase well. But thoughts/comments? If it looks feasible, and sensible I'll put the time into working exact details/implementing.

[c0d3z3r0]

I like the idea of having a separate tool. Maybe this can be added to zstream? https://openzfs.github.io/openzfs-docs/man/master/8/zstream.8.html