Re: Experimental btrfs encryption

2016-09-21 Thread Anand Jain
So there's a matrix of possible configurations. If you're doing a reflink between subvolumes and you're doing a subvolume granular encryption and you don't have keys to the source subvolume, the reflink shouldn't be allowed. Right, this is working. If you do have keys, any new writes are

Re: Experimental btrfs encryption

2016-09-20 Thread Chris Mason
On 09/19/2016 10:50 PM, Theodore Ts'o wrote: On Mon, Sep 19, 2016 at 08:32:34PM -0400, Chris Mason wrote: That key is used to protect the contents of the data file, and to encrypt filenames and symlink targets --- since filenames can leak significant information about what the user is doing.

Re: Experimental btrfs encryption

2016-09-19 Thread Zygo Blaxell
On Mon, Sep 19, 2016 at 10:50:41PM -0400, Theodore Ts'o wrote: > On Mon, Sep 19, 2016 at 08:32:34PM -0400, Chris Mason wrote: > One of the other things that was in the original design, but which got > dropped in our initial implementation, was the concept of having the > per-inode key wrapped by mu

Re: Experimental btrfs encryption

2016-09-19 Thread Anand Jain
Hi Ted, I appreciate your email, thanks for taking time to review. Before I wrote the current version, I had a version which used fs/crypto. BTRFS needs a highly scalable solution, I am experimenting and evaluating, integration with fs/crypto is needed, I will discuss that in the fsdevel

Re: Experimental btrfs encryption

2016-09-19 Thread Alex Elsayed
Taking a stab at a different way of replying, to try and keep Ted in the loop. On Monday, 19 September 2016 22:50:41 PDT Theodore Ts'o wrote: > On Mon, Sep 19, 2016 at 08:32:34PM -0400, Chris Mason wrote: > > > > That key is used to protect the contents of the data file, and to > > > > encrypt fil

Re: Experimental btrfs encryption

2016-09-19 Thread Theodore Ts'o
On Mon, Sep 19, 2016 at 08:32:34PM -0400, Chris Mason wrote: > > > That key is used to protect the contents of the data file, and to > > > encrypt filenames and symlink targets --- since filenames can leak > > > significant information about what the user is doing. (For example, > > > in the downl

Re: Experimental btrfs encryption

2016-09-19 Thread Alex Elsayed
On Mon, 19 Sep 2016 20:32:34 -0400, Chris Mason wrote: > On 09/19/2016 04:58 PM, Alex Elsayed wrote: >> When someone says "pretty simple" regarding cryptography, it's often >> neither pretty nor simple :P >> >> The issue, here, is that inodes are fundamentally not a safe scope to >> attach that

Re: Experimental btrfs encryption

2016-09-19 Thread Chris Mason
On 09/19/2016 04:58 PM, Alex Elsayed wrote: On Mon, 19 Sep 2016 11:15:18 -0400, Theodore Ts'o wrote: (I'm not on linux-btrfs@, so please keep me on the cc list. Or perhpas better yet, maybe we can move discussion to the linux-fsdevel@ list.) I apologize if this doesn't keep you in the CC, as

Re: Experimental btrfs encryption

2016-09-19 Thread Alex Elsayed
On Mon, 19 Sep 2016 11:15:18 -0400, Theodore Ts'o wrote: > (I'm not on linux-btrfs@, so please keep me on the cc list. Or perhpas > better yet, maybe we can move discussion to the linux-fsdevel@ > list.) I apologize if this doesn't keep you in the CC, as I'm posting via gmane. > Hi Anand, > >

Re: Experimental btrfs encryption

2016-09-19 Thread Theodore Ts'o
(I'm not on linux-btrfs@, so please keep me on the cc list. Or perhpas better yet, maybe we can move discussion to the linux-fsdevel@ list.) Hi Anand, After reading this thread on the web archives, and seeing that some folks seem to be a bit confused about "vfs level crypto", fs/crypto, and ext4