6 ms·

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 woul

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…

tptacek 10y ago
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?
- black_knight 10y ago
  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.
  - tptacek 10y ago
    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.
    - tedunangst 10y ago
      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.
      - tptacek 10y ago
        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.
        tedunangst 10y ago
        This is why ninjas partition their disk into lots of devices. :)
        Annatar 10y ago
        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.
    - Vegemeister 10y ago
      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.

tptacek 10y ago

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?

black_knight 10y ago
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.
- tptacek 10y ago
  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.
  - tedunangst 10y ago
    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.
    - tptacek 10y ago
      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.
      - tedunangst 10y ago
        This is why ninjas partition their disk into lots of devices. :)
        Annatar 10y ago
        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.
  - Vegemeister 10y ago
    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.