ZFS Native Encryption by Tom Caputi

What people said

drbawb · 2022-12 · Recommendation

The problem is that a stream cipher is going to have some per-object uniqueness (a salt, IV, etc.), so by design even if you feed it related input blocks you will get different output blocks. This is, of course, antithetical to deduplication: so you need to check/store the hash of the input before it goes through the cipher. The presentation about ZFS' native encryption[1] covers many of these sorts of trade-offs necessary to do full-disk encryption at scale. [1]: [VIDEO]

Read the original HN comment ↗

dchest · 2017-05 · Recommendation

On the contrary, it makes it suitable for file systems! File systems are not block devices, they are data structures on top of block devices — it's the job of these data structures to keep stuff, such as data, inodes, and... keys, and IVs, and MACs, checksums, etc. TFS uses Speck in XEX mode (edit: I just realized you're the author, so you already know that :). tptacek wrote a nice post about it: [LINK] and I quote: "If you’re encrypting a filesystem and not disk blocks, still don’t use XTS! Filesystems have format-awareness and flexibility. Filesystems can do a much better job of encrypting a disk than simulated hardware encryption can." Edit: check out this presentation on how encryption was bolted on ZFS: [VIDEO] (slides: [LINK] ) It's not perfect, but it provides data authentication by reusing checksum fields for storing MACs. Edit 2: also check out bcachefs encryption design doc: [LINK] (also not perfect, but uses proper AEAD — ChaCha20-Poly1305. I sent some questions and suggestions to the author, but received no reply :/)

Read the original HN comment ↗

wspeirs · 2017-06 · Reference

I work with Tom at Datto. He presented all of his design decisions at the OpenZFS developer conference here: [LINK] Slides: [LINK] Video: [VIDEO]

Read the original HN comment ↗