Re: [PATCH] fscrypt: add a documentation file for filesystem-level encryption

[Eric Biggers <ebiggers3@gmail.com>]

On Tue, Aug 22, 2017 at 11:35:20PM +0800, Anand Jain wrote:
> >>
> >>   I think AE is the only good solution for this, File-name encryption at
> >>this stage won't solve any kind of Evil Maid attack, (as it was quoted
> >>somewhere else in ML).
> >>
> >>
> >>  Further, below,  is define but not used.
> >>-----
> >>  #define FS_AES_256_GCM_KEY_SIZE		32
> >>-----
> >>
> >
> >Yes, authenticated encryption with AES-256-GCM was in an older version of the
> >ext4 encryption design document.  But unfortunately it was never really thought
> >through. The primary problem, even ignoring rollback protection, is that there
> >is nowhere to store the per-block metadata (GCM authentication tag and IV) *and*
> >have it updated atomicly with the block contents.  Recently, dm-integrity solves
> >this at the block device layer, but it uses data journaling which is very
> >inefficient.  This maybe could be implemented more efficiently on a COW
> >filesystem like BTRFS.  But even after that, another problem is that
> >authenticated encryption of file contents only would not stop an attacker from
> >swapping around blocks, files, directories, or creating links, etc.
> 
> 
>  Some of the problems to be solved in this area are quite
> interesting and challenging and IMO BTRFS fits nicely. Per extent AE
> for BTRFS is drafted, it needs scrutiny and constructive feedback.
> 
> Thanks, Anand
> 
> 
> >Eric
> >

Where is the code?  Is there a design document, and it is it readable by people
not as familiar with btrfs?  Is the API compatible with ext4, f2fs, and ubifs?

Eric