Re: [RFC] Experimental btrfs encryption

[Martin Steigerwald <martin@lichtvoll.de>]

On Mittwoch, 2. März 2016 09:06:57 CET Qu Wenruo wrote:
> And maybe I just missed something, but the filename seems not touched, 
> meaning it will leak a lot of information.
> Just like default eCryptfs behavior.
> 
> I understand that's an easy design and it's not a high priority thing, 
> but I hope we can encrypt the subvolume tree blocks too, if using 
> per-subvolume policy.
> To provide a feature near block-level encryption.

I´d really love an approach to at least optionally be able to hide the 
metadata structure completely except for which blocks on the block device are 
allocated. I.e. not just encrypting filenames, but encrypting the directory 
structure, amount of files, their dates, their sizes. I am not sure whether 
BTRFS can allow this and still be at least btrfs check´able without unlocking 
the encryption key. Ideally this could even be backuped by an btrfs send/
receive as a kind opaque stream.

This would excel BTRFS encryption support over anything thats available with 
Ext4, F2FS, ecryptfs and encfs. It would ideal for having encryption on SSD, 
no need to encrypted unallocated blocks, but still most of the advantages of 
block level encryption, even of some would argue that you can find something 
out when you check which blocks are allocated or not, and of course the total 
size of the subvolume and which chunks it allocates are known.

I would the this as requirement for any initial approach and be happy about 
anything that does file name encryption like ecryptfs or the Ext4/F2FS 
approach, but if the subvolume specifics of BTRFS can be used to encrypted 
more of the metadata then even better!

Thanks,
-- 
Martin