Re: Btrfs Fscrypt Design Document

[Eric Biggers <ebiggers@kernel.org>]

On Thu, Oct 21, 2021 at 11:34:19AM -0700, Omar Sandoval wrote:
> Hello,
> 
> I've been working on adding fscrypt support to Btrfs. Btrfs has some
> features (namely, reflinks and snapshots) that don't work well with the
> existing fscrypt encryption policies. I've been discussing and
> prototyping how to support these Btrfs features with fscrypt, so I
> figured it was high time I write it down and loop in the fscrypt
> developers as well.
> 
> Here is the Google Doc:
> https://docs.google.com/document/d/1iNnrqyZqJ2I5nfWKt7cd1T9xwU0iHhjhk9ALQW3XuII/edit?usp=sharing
> 
> Please feel free to comment there or via email.
> 

Just some preliminary comments:

Given that you need reflinking to remain supported, for file contents encryption
I think it's the right choice to store the IVs explicitly rather than have them
determined by the offset within the file.

How many derived encryption keys to use is somewhat orthogonal to that.  As I
mentioned in my other mail, you could still have one key per extent rather than
one per encryption policy as you're proposing.  I'm *guessing* it wouldn't be
practical, and I don't consider it to be required (just preferable), but the
document doesn't discuss this possibility at all.

Storing just the "starting IV" for each extent also makes sense, assuming that
you only want to support an unauthenticated mode such as AES-XTS.  However,
given that btrfs is a copy-on-write filesystem and thus can support per-block
metadata, a natural question is why not support an authenticated mode such as
AES-GCM, with a nonce and authentication tag stored per block?  Have you thought
about this?

Now, I personally think that authenticating file contents only wouldn't give
much benefit, and whole-filesystem authentication would be needed to get a real
benefit.  But "why aren't you using an authenticated mode" is a *very* common
question, so you need an answer to that -- or ideally, just support it if it
isn't much work.

What is your proposal for how filenames encryption would work when the
EXPLICIT_IV flag is used?  That doesn't appear to be mentioned.

Finally, the proposal to allow encrypting the changed data of snapshots is a
larger departure from the fscrypt model.  I'm still trying to wrap my head
around how that could work.  Could you provide any more details about that?
E.g. what metadata would actually be stored on-disk, and how would it be used?
When would things be done in terms of filesystem operations?  E.g. let's say I
open a file for writing -- would the encryption key be set up right away, or
would it not happen until I actually write data?

- Eric