On Fri, 16 Sep 2016 23:58:31 -0700, Eric Biggers wrote: > On Tue, Sep 13, 2016 at 09:39:46PM +0800, Anand Jain wrote: >> >> This patchset adds btrfs encryption support. >> >> > Hi Anand,
<snip> > Note: even better would be an authenticated encryption mode. That isn't > yet done by ext4 or f2fs --- I think because there wasn't a good place > to store a per-page authentication tag. It would be interesting to know > whether this would be possible for btrfs. 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. 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. <snip> -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
