On Sat, Sep 17, 2016 at 07:13:45AM +0000, Alex Elsayed wrote: > IMO, this is already a flawed framing - in particular, if encrypting at > the extent level, one _should not_ be encrypting (or authenticating) > individual pages. The meaningful unit is the extent, and encrypting at > page granularity puts you right back where dmcrypt is: dealing with fixed- > size space, and needing to find somewhere else to put the auth tag. > > This is not a good place to be, and I strongly suspect it motivated > choosing XTS in the first place - something I feel is an _error_ in the > long run, and a dangerous one. (IMO, anything _but_ AEAD should be > forbidden in FS-level encryption.) > > In a nonce-misuse-resistent AEAD, there _is_ no auth tag: There's some > amount of inherent ciphertext expansion, and the ciphertext _cannot be > decrypted at all_ unless all of it is present. In essence, a built-in all- > or-nothing transform. > > You could, potentially, chop off part of that and store it elsewhere, but > now you're dealing with significant added complexity, for absolutely zero > gain.
That would be true if the problem were not already long solved in btrfs. The 32-bit CRC tree stores 4 bytes per block separately and efficiently. With minor changes it can store a 32-byte HMAC for each block. > If you're _not_ using a nonce-misuse-resistant AEAD, it's even worse: > keeping the tag out-of-band makes it far too easy to fail to verify it, > or verify it only after decrypting the ciphertext to plaintext. Bluntly: > that is an immediate security vulnerability. > > tl;dr: Don't encrypt pages, encrypt extents. They grow a little for the > auth tag, and that's fine. > > Btrfs already handles needing to read the full extent in order to get a > page out of it with compression, anyway. It does, but compressed extents are limited to 128K. Uncompressed extents come in sizes up to 128M, far too large to read in their entirety for many applications.
signature.asc
Description: Digital signature
