Hacker News Reader

Comment by daenney | Hacker News Reader

As noted in the PR, in this case it's a licensing issue.

No, I mean why would ZFS have anything to do with encryption at all?

It doesn't seem to be a filesystem issue, rather something you put underneath it (encrypting the block device, no matter what file system is on top) or on top of it (encrypting separate files).

Encrypting on top of ZFS negates ZFS' compression and de-duplication. My understanding is that this implementation preserves both of those. For example, ZFS can compress before encrypting.

In order to do filesystem encryption properly, it needs to be done at the file layer, not the block layer. Block-level encryption is not authenticated because there are no extra bytes to add the authentication tag.

If a ciphertext is not authenticated, it can be trivially tampered with. This means that someone with access to the encrypted drive could add backdoors or otherwise tamper with the executables and data even though it is encrypted.

> If a ciphertext is not authenticated, it can be trivially tampered with.

Shouldn't it be impossible to forge a plaintext without the key for a good encryption algorithm?

I imagine a good algorithm not to be just key -> pseudorandom stuff that is XORed with data, but something that has cascading. Change a bit anywhere, and a whole block changes unpredictably. Include the physical position of the block in the key, so that it impossible to copy blocks around to duplicate data.

You can perfectly fine divide the block device into a bit smaller chunks so that you can fit a MAC or similar at the end.

This is how FreeBSD's GELI (which has authenticated encryption for blockdevices) did it. For every 4k data block it presented up the stack, it consumed 9 512 sectors on disk. Each of them contained 480 bytes, the rest for MAC.

With 4k native drives, this became completely impractical. To keep ratios similar, you would have to present 32k byte devices up the stack, which filesystems have troubles with. Or have 1 MAC sector per data sector or similar, cutting your storage in half.

My understanding is that in practice this is quite hard to do. As far as I know, none of the mainstream block-layer encryption systems (BitLocker, FileVault, dm-crypt) provide authenticated encryption.

Here's a short thread about the problems with adding it to dm-crypt: http://comments.gmane.org/gmane.linux.kernel.device-mapper.d...

I'm sure you can find more threads if you look around.

Thanks! That’s good to know. Indeed, encryption without authentication is poor security.

With this you can encrypt one dataset and leave another unencrypted, on the same block device, paying the cost only or the encrypted one.

Which means you can also potentially use different keys for each encrypted filesystem as well, one for each user or various other scenarios

That’s interesting, but it again seems like something which can be implemented independently of the particular choice of file system.

Only sort of?

ZFS is both filesystem and logical volume abstraction, so to implement different keys on different "filesystems" on ZFS, you'd need to expose them as block devices, not filesystems, and then use your encryption du jour on them, then your filesystem atop that - which also kills most of your compression or encryption properties, since you're doing it before ZFS sees the data, so to speak.

I guess I was thinking more like a 9P[0] approach where a file system can be given to a module (or any program) and based on it the module can export a related file system. For example the module would encrypt the files before storing it to the given file system.

However, I realise this does not quite fit into the current kernel architectures.

[0] https://en.wikipedia.org/wiki/9P_(protocol)

What is a dataset in this setting?

Think flexible-sized partitions. Then forget it again because it is too wrong.

The one really nice scenario this opens up that is discussed in the pull request linked in another comment:

  1. Server A has an encrypted dataset in pool foo, currently not decrypted
  2. A can send full or incremental streams from that dataset to server B
     without decrypting
  3. B can receive those streams and import them as encrypted
     datasets into the pool without decrypting or really ever having
     even seen the keys
  4. Server A can restore from B as required
  5. The owner of the key material can log into B and unlock
     the dataset as if it were on A

This is a really nice, accessible way for encrypted remote backups.

Cool. As I mentioned in some other comment, I would really have to look into the details before I could use and trust such an encrypted system, to understand the guarantees provided.

It's a feature that trades off layering purity (which ZFS has never adhered to) for increased usability.

I see. When crypto is concerned, this kind of purity seems attractive though… Easier to reason about when using it.

If I were to use ZFS’s native crypto I would have to look into the details of their implementation to understand what guarantees are provided, and where in the stack the crypto is applied etc…

In fact, it's significantly harder to reason about encryption at the block layer, and not just because it's difficult to reason about the most popular construction (XTS). Among other things, you have to come up with a semantic for handling authentication failures at a sector level. What does it mean for one sector of a file to fail authentication? Have you lost the whole file? Do you fill with zeroes? How do you signal the precise error to the kernel or users?

The semantics seem pretty strait forward. That sector is untrusted. You do not fill with zeroes(!), but fail as hard as you can.

I understand that kernel currently may not have any semantics for files or sectors failing authentication, but that issue would doesn't seem to depend on the file/sector dilemma, and would have to be solved anyhow.

To me, this is very simple:

File-level encryption has total format flexibility. A filesystem can store arbitrary metadata. It turns out that strong encryption schemes want internal metadata. You can go through contortions --- contortions no block encryption scheme currently goes through --- to get some sort of space for metadata at the block layer, at significant expense. Or you can get it for free with files.

File-level encryption is also message-aware. Encryption cares about the boundaries between messages (just for instance: because it leaves no ambiguity about the set of disk sectors that makes up any particular file at any particular moment in time). Block-level crypto can't provide this; it's by definition oblivious to messages.

We have block-level crypto because it's a cheap easy win, for the minimal security it provides. If the FBI is interdicting you, block crypto isn't going to help you: they incurred weeks worth of planning before anyone with handcuffs approached you, and the extra planning it takes to make sure they grab you when your key is resident is a rounding error. But if you leave your laptop full of financial secrets in a taxi cab, block crypto will probably keep you from having to roll all your keys, change your account numbers, notifying your clients, etc.

Is there a way to do file-level encryption without leaking the number of files and their sizes? Because that seems much worse than any known problem with block-level encryption.

But won't the FBI also wait to make the grab when using filesystem encryption? We're not talking about some filesystem that uses unique passwords for every file.

Unlike block encryption, filesystem encryption doesn't have to be all-or-none; you can have lots of different keys, unlock on a directory-by-directory basis, whatever. There's room for arbitrary metadata. If you're using your computer at all, block encryption is unlikely to help you.

I'm not saying any particular extant system does those things; I'm just saying they're a possibility for filesystems and foreclosed for device-level encryption.

This is why ninjas partition their disk into lots of devices. :)

Except that partitioning a single device completely falls apart when using ZFS, as zpool is designed to manage entire drives, and managing multiple partitions as vdevs on a single device would not only kill performance, but severely imperil data redundancy. Once the drive kicked the bucket, all the vdevs would be gone too, causing an outage.

Reply on news.ycombinator.com