Re: [RFC] Preliminary BTRFS Encryption

On Mon, Sep 19, 2016 at 07:50:07PM +, Alex Elsayed wrote: > > That would be true if the problem were not already long solved in btrfs. > > The 32-bit CRC tree stores 4 bytes per block separately and efficiently. > > With minor changes it can store a 32-byte HMAC for each block. > > I disagree

Re: [RFC] Preliminary BTRFS Encryption

On Mon, 19 Sep 2016 14:08:06 -0400, Zygo Blaxell wrote: > On Sat, Sep 17, 2016 at 06:37:16AM +, Alex Elsayed wrote: >> > Encryption in ext4 is a per-directory-tree affair. One starts by >> > setting an encryption policy (using an ioctl() call) for a given >> > directory, which must be empty

Re: [RFC] Preliminary BTRFS Encryption

On Mon, 19 Sep 2016 14:57:33 -0400, Zygo Blaxell wrote: > On Sat, Sep 17, 2016 at 07:13:45AM +, Alex Elsayed wrote: >> 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

Re: [RFC] Preliminary BTRFS Encryption

On Sat, Sep 17, 2016 at 07:13:45AM +, Alex Elsayed wrote: > 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

Re: [RFC] Preliminary BTRFS Encryption

On Sat, Sep 17, 2016 at 06:37:16AM +, Alex Elsayed wrote: > > Encryption in ext4 is a per-directory-tree affair. One starts by > > setting an encryption policy (using an ioctl() call) for a given > > directory, which must be empty at the time; that policy includes a > > master key used for all

Re: [RFC] Preliminary BTRFS Encryption

On 09/18/2016 04:35 AM, David Sterba wrote: On Fri, Sep 16, 2016 at 07:56:02PM +0800, Anand Jain wrote: however here below is the quick example on the cli usage. Please try out, let me know if I have missed something. Also would like to mention that a review from the security experts is

Re: [RFC] Preliminary BTRFS Encryption

On Fri, Sep 16, 2016 at 07:56:02PM +0800, Anand Jain wrote: > > > >> however here below is the quick example > >> on the cli usage. Please try out, let me know if I have missed something. > >> > >> Also would like to mention that a review from the security experts is due, > >> which is important

Re: [RFC] Preliminary BTRFS Encryption

On Sat, Sep 17, 2016 at 10:12 AM, Anand Jain wrote: > btrfs keeps it only in-memory and key hash goes to the disk. > Further in the long we need an integration with key management > system as well. Maybe LUKS2 is usable for this part, and still adaptable since it's

Re: [RFC] Preliminary BTRFS Encryption

On Sat, Sep 17, 2016 at 12:38:30AM -0400, Zygo Blaxell wrote: > There's also a nasty problem with the extent tree--there's only one per > filesystem, it's shared between all subvols and block groups, and every > extent in that tree has back references to the (possibly encrypted) subvol > trees.

Re: [RFC] Preliminary BTRFS Encryption

Hi Eric, Thanks for the constructive feedback, pls see inline below. On 09/17/2016 02:58 PM, Eric Biggers wrote: On Tue, Sep 13, 2016 at 09:39:46PM +0800, Anand Jain wrote: This patchset adds btrfs encryption support. Hi Anand, I'm part of a team that will be maintaining and

Re: [RFC] Preliminary BTRFS Encryption

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, > Note: even better would be an authenticated encryption mode. That isn't > yet done by ext4 or f2fs --- I

Re: [RFC] Preliminary BTRFS Encryption

On Tue, Sep 13, 2016 at 09:39:46PM +0800, Anand Jain wrote: > > This patchset adds btrfs encryption support. > Hi Anand, I'm part of a team that will be maintaining and improving ext4 encryption. Because f2fs now shares much of the code, it will benefit from the ext4 encryption work too. It

Re: [RFC] Preliminary BTRFS Encryption

On Sat, 17 Sep 2016 00:38:30 -0400, Zygo Blaxell wrote: > On Fri, Sep 16, 2016 at 06:49:53AM +, Alex Elsayed wrote: >> The main issue I see is that subvolumes as btrfs has them _do_ >> introduce novel concerns - in particular, how should snapshots interact >> with keying (and nonces)? None of

Re: [RFC] Preliminary BTRFS Encryption

On Fri, Sep 16, 2016 at 06:49:53AM +, Alex Elsayed wrote: > The main issue I see is that subvolumes as btrfs has them _do_ introduce > novel concerns - in particular, how should snapshots interact with keying > (and nonces)? None of the AEADs currently in the kernel are nonce-misuse >

Re: [RFC] Preliminary BTRFS Encryption

On Thu, Sep 15, 2016 at 10:24:02AM -0400, Austin S. Hemmelgarn wrote: > On 2016-09-15 10:06, Anand Jain wrote: > >>How does this handle cloning of extents? Can extents be cloned across > >>subvolume boundaries when one of the subvolumes is encrypted? > > > > Yes only if both the subvol keys

Re: [RFC] Preliminary BTRFS Encryption

however here below is the quick example on the cli usage. Please try out, let me know if I have missed something. Also would like to mention that a review from the security experts is due, which is important and I believe those review comments can be accommodated without major changes from

Re: [RFC] Preliminary BTRFS Encryption

On 09/16/2016 09:12 AM, Dave Chinner wrote: On Tue, Sep 13, 2016 at 09:39:46PM +0800, Anand Jain wrote: This patchset adds btrfs encryption support. The main objective of this series is to have bugs fixed and stability. I have verified with fstests to confirm that there is no regression. A

Re: [RFC] Preliminary BTRFS Encryption

On 09/15/2016 07:47 PM, Alex Elsayed wrote: On Thu, 15 Sep 2016 19:33:48 +0800, Anand Jain wrote: Thanks for commenting. pls see inline below. On 09/15/2016 12:53 PM, Alex Elsayed wrote: On Tue, 13 Sep 2016 21:39:46 +0800, Anand Jain wrote: This patchset adds btrfs encryption support.

Re: [RFC] Preliminary BTRFS Encryption

For the most part, I agree with you, especially about the strategy being backward - and file encryption being a viable more-easily-implementable direction. However, you are doing yourself a disservice to compare btrfs' features as a "re-implementation" of existing tools. The existing tools

Re: [RFC] Preliminary BTRFS Encryption

On Thu, Sep 15, 2016 at 10:24:02AM -0400, Austin S. Hemmelgarn wrote: > >> What happens when you try to > >> clone them in either case if it isn't supported? > > > > Gets -EOPNOTSUPP. > That actually makes more sense than what my first thought for a return > code was (-EINVAL). Should be

Re: [RFC] Preliminary BTRFS Encryption

On Tue, Sep 13, 2016 at 09:39:46PM +0800, Anand Jain wrote: > This patchset adds btrfs encryption support. > > The main objective of this series is to have bugs fixed and stability. > I have verified with fstests to confirm that there is no regression. > > A design write-up is coming next,

Re: [RFC] Preliminary BTRFS Encryption

On Fri, 16 Sep 2016 11:12:13 +1000, Dave Chinner wrote: > On Tue, Sep 13, 2016 at 09:39:46PM +0800, Anand Jain wrote: >> >> This patchset adds btrfs encryption support. >> >> The main objective of this series is to have bugs fixed and stability. >> I have verified with fstests to confirm that

Re: [RFC] Preliminary BTRFS Encryption

On Fri, 16 Sep 2016 11:12:13 +1000 Dave Chinner wrote: > > As of now these patch set supports encryption on per subvolume, as > > managing properties on per subvolume is a kind of core to btrfs, which is > > easier for data center solution-ing, seamlessly persistent and easy

Re: [RFC] Preliminary BTRFS Encryption

On Tue, Sep 13, 2016 at 09:39:46PM +0800, Anand Jain wrote: > > This patchset adds btrfs encryption support. > > The main objective of this series is to have bugs fixed and stability. > I have verified with fstests to confirm that there is no regression. > > A design write-up is coming next,

Re: [RFC] Preliminary BTRFS Encryption

On 2016-09-15 10:06, Anand Jain wrote: Thanks for comments. Pls see inline as below. On 09/15/2016 07:37 PM, Austin S. Hemmelgarn wrote: On 2016-09-13 09:39, Anand Jain wrote: This patchset adds btrfs encryption support. The main objective of this series is to have bugs fixed and

Re: [RFC] Preliminary BTRFS Encryption

Thanks for comments. Pls see inline as below. On 09/15/2016 07:37 PM, Austin S. Hemmelgarn wrote: On 2016-09-13 09:39, Anand Jain wrote: This patchset adds btrfs encryption support. The main objective of this series is to have bugs fixed and stability. I have verified with fstests to

Re: [RFC] Preliminary BTRFS Encryption

On Thu, 15 Sep 2016 19:33:48 +0800, Anand Jain wrote: > Thanks for commenting. pls see inline below. > > On 09/15/2016 12:53 PM, Alex Elsayed wrote: >> On Tue, 13 Sep 2016 21:39:46 +0800, Anand Jain wrote: >> >>> This patchset adds btrfs encryption support. >>> >>> The main objective of this

Re: [RFC] Preliminary BTRFS Encryption

On 2016-09-13 09:39, Anand Jain wrote: This patchset adds btrfs encryption support. The main objective of this series is to have bugs fixed and stability. I have verified with fstests to confirm that there is no regression. A design write-up is coming next, however here below is the quick

Re: [RFC] Preliminary BTRFS Encryption

Thanks for commenting. pls see inline below. On 09/15/2016 12:53 PM, Alex Elsayed wrote: On Tue, 13 Sep 2016 21:39:46 +0800, Anand Jain wrote: This patchset adds btrfs encryption support. The main objective of this series is to have bugs fixed and stability. I have verified with fstests to

Re: [RFC] Preliminary BTRFS Encryption

Thanks for the comments. Pls see inline below.. On 09/15/2016 01:38 PM, Chris Murphy wrote: On Tue, Sep 13, 2016 at 7:39 AM, Anand Jain wrote: This patchset adds btrfs encryption support. The main objective of this series is to have bugs fixed and stability. I have

Re: [RFC] Preliminary BTRFS Encryption

On Tue, Sep 13, 2016 at 7:39 AM, Anand Jain wrote: > > This patchset adds btrfs encryption support. > > The main objective of this series is to have bugs fixed and stability. > I have verified with fstests to confirm that there is no regression. > > A design write-up is

Re: [RFC] Preliminary BTRFS Encryption

On Tue, 13 Sep 2016 21:39:46 +0800, Anand Jain wrote: > This patchset adds btrfs encryption support. > > The main objective of this series is to have bugs fixed and stability. > I have verified with fstests to confirm that there is no regression. > > A design write-up is coming next, however

Re: [RFC] Preliminary BTRFS Encryption

> Am 14.09.2016 um 09:02 schrieb Anand Jain : > > > > Wilson, > > Thanks for commenting. Pls see inline below.. > >> On 09/14/2016 12:42 AM, Wilson Meier wrote: >> Hi Anand, >> >> these are great news! Thanks for yor work. I'm looking forward to use the >>

Re: [RFC] Preliminary BTRFS Encryption

Wilson, Thanks for commenting. Pls see inline below.. On 09/14/2016 12:42 AM, Wilson Meier wrote: Hi Anand, these are great news! Thanks for yor work. I'm looking forward to use the encryption. I would like to ask a few question regarding the feature set. 1. is encryption of an existing,

Re: [RFC] Preliminary BTRFS Encryption

Hi Anand, these are great news! Thanks for yor work. I'm looking forward to use the encryption. I would like to ask a few question regarding the feature set. 1. is encryption of an existing, filled and unencrypted subvolume without manually moving the data possible? 2. What about encrypting

[RFC] Preliminary BTRFS Encryption

This patchset adds btrfs encryption support. The main objective of this series is to have bugs fixed and stability. I have verified with fstests to confirm that there is no regression. A design write-up is coming next, however here below is the quick example on the cli usage. Please try out,