btrfs native encryption

btrfs native encryption

[Filip Bystricky]

Dear btrfs maintainers,
Google is evaluating btrfs for its potential use in android, but
currently the lack of native file-based encryption unfortunately makes
it a nonstarter. According to the FAQ (specifically the answer to
"Does btrfs support encryption"), nobody is currently working on this.
How up-to-date is that answer, and are there any new plans to add
native FBE in the future?

Thanks,
Filip Bystricky

Re: btrfs native encryption

[Hugo Mills]

[-- Attachment #1: Type: text/plain, Size: 1227 bytes --]

On Fri, Jun 09, 2017 at 08:50:12AM -0700, Filip Bystricky wrote:
> Dear btrfs maintainers,
> Google is evaluating btrfs for its potential use in android, but
> currently the lack of native file-based encryption unfortunately makes
> it a nonstarter. According to the FAQ (specifically the answer to
> "Does btrfs support encryption"), nobody is currently working on this.
> How up-to-date is that answer, and are there any new plans to add
> native FBE in the future?

   There were initial patches from Anand Jain back in September, but
they weren't well-received in terms of the (lack of) cryptography
design. IIRC, the patches provided file-level data encryption without
encrypting metadata. I haven't seen anything since then (although
Anand was planning on doing a session on btrfs encryption at LSF/MM in
March -- I don't know if that happened, or what the outcome was).

   So, there's some interest in a fairly minimal implementation, but
progress doesn't seem to be particularly fast.

   Hugo.

-- 
Hugo Mills             | "Are you the man who rules the Universe?" "Well, I
hugo@... carfax.org.uk | try not to."
http://carfax.org.uk/  |
PGP: E2AB1DE4          |                    Life, the Universe and Everything.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: btrfs native encryption

[Chris Murphy]

On Fri, Jun 9, 2017 at 9:50 AM, Filip Bystricky
<filipbystricky@google.com> wrote:
> Dear btrfs maintainers,
> Google is evaluating btrfs for its potential use in android, but
> currently the lack of native file-based encryption unfortunately makes
> it a nonstarter. According to the FAQ (specifically the answer to
> "Does btrfs support encryption"), nobody is currently working on this.
> How up-to-date is that answer, and are there any new plans to add
> native FBE in the future?


The ext4 and f2fs encryption implementations were moved to the VFS, so
in theory it can be used for XFS and Btrfs. A usability gotcha that
probably is manageable on Android is dealing with inheritance of
encryption when making snapshots, and dealing with reflinks.

https://lwn.net/Articles/677620/

-- 
Chris Murphy

Re: btrfs native encryption

[Anand Jain]

   For phase-1 the idea was to make btrfs encryption inline with 
fs/crytpo which wasn't available when it started, so certainly there are 
things which could straight away filter out after its known what went 
into fs/crypto from ext4, especially the cryptography part.

  Now, 4.10 kernel based, btrfs encryption using fs/crypto is here [1]. 
It has under gone limited testing by me and yet to arrive at a 
conclusion on the file-name encryption, though its discussions are here 
[2], and patches aren't sent out to the BTRFS ML yet.


[1] Phase-1.
   Progs: https://github.com/asj/btrfs-progs-fscryptv1
   Kernel: https://github.com/asj/linux-btrfs-fscryptv1

[2] File name encryption discussions are here:
  (I don't see some of the emails I have in the google search, so 
instead I have listed the subject for your search).
    On the ext4 ML:
     Sub: fs/crypto: file-name encryption, optional ?
     Sub: fs/crypto: root read-access without key

Thanks, Anand

Re: btrfs native encryption

[Anand Jain]

>  dealing with inheritance of
> encryption when making snapshots, and dealing with reflinks.

  Right. To address this, there is a proposal to bring encryption down 
to the extent level, it solves these limitations.

Thanks, Anand

Re: btrfs native encryption

[David Sterba]

On Fri, Jun 09, 2017 at 08:50:12AM -0700, Filip Bystricky wrote:
> Dear btrfs maintainers,
> Google is evaluating btrfs for its potential use in android, but
> currently the lack of native file-based encryption unfortunately makes
> it a nonstarter.

The file-based encryption is covered by the fscrypt API, that's
implemented in ext4/f2fs, so implementing that in btrfs could allow you
to start evaluating btrfs. As other pointed, the usecases with snapshots
and reflinks need to be reviewed.

> According to the FAQ (specifically the answer to
> "Does btrfs support encryption"), nobody is currently working on this.
> How up-to-date is that answer, and are there any new plans to add
> native FBE in the future?

Wiki is a snapshot of status, knowledge and best practices from mixed
times, so not everything is up to date or accurate. That no one is
working on encryption is partially true, as we've seen some proposed
patches that received objections and from my perspective are not close
to being considered for merging.

The fscrypt functionality has been designed and the API defined, so it's
a matter of implementation on the btrfs side. Anything else is in the
phase of design and prototyping.

Re: btrfs native encryption

[David Sterba]

On Mon, Jun 12, 2017 at 02:40:38PM +0200, David Sterba wrote:
> On Fri, Jun 09, 2017 at 08:50:12AM -0700, Filip Bystricky wrote:
> > Dear btrfs maintainers,
> > Google is evaluating btrfs for its potential use in android, but
> > currently the lack of native file-based encryption unfortunately makes
> > it a nonstarter.
> 
> The file-based encryption is covered by the fscrypt API, that's
> implemented in ext4/f2fs, so implementing that in btrfs could allow you
> to start evaluating btrfs.

For reference I'll add it here,
https://github.com/asj/linux-btrfs-fscryptv1 seems to implement it, I've
only scrolled through it so I don't know how usable is it in this state.

Re: Btrfs native encryption

[Mark Harmstone]

Fair enough. I imagine the intersection of "people who know about filesystems" and "people who know about crypto" is pretty small anyway.

There were solid reasons why fscrypt wasn't feasible - IIRC, it was because the XTS scheme that it uses ties a block's encryption to its physical location on disk, which breaks balancing. You could use the logical location within the file instead, but that's horrendously insecure (all files with the same cleartext would have the same ciphertext).

My version gets round this by randomizing the initialization vector whenever an extent is created, and storing this with the metadata. It also works with reflink copies - there's no reason why you can't do this with encrypted files.

Omar, or whoever, is there anything I can do to speed this along? I was careful not to repeat the mistakes that other people here have made while tackling the same issue previously, so it'd be a shame to let it go to waste.

On 27/4/20 5:49 am, Chris Murphy wrote:
> On Sun, Apr 26, 2020 at 8:25 AM Mark Harmstone <mark@harmstone.com> wrote:
>> Last thing I heard was that Omar Sandoval at Facebook was looking into it. I never heard anything back about my patches, though.
> I think the biggest difficulty with that patchset isn't as much the
> patchset, but the bandwidth of people who can review it. It was a
> complex patchset and didn't use fscrypt. (For reasons that are
> explained, but then also at least originally the Btrfs maintainers
> wanted to initially implement an fscrypt/VFS approach. Maybe it's too
> difficult.)
>
> I'm curious whether Omar is working on something and what the time
> frame could plausibly be. In the meantime, other approaches are being
> explored, based on LUKS encrypted loop mounted files, as in
> https://systemd.io/HOME_DIRECTORY/
>
> Btrfs has advantages here, including asynd discards and online fs
> resize, in case someone wants to attempt to manage the ensuing fantasy
> of sparse backing files. The loss of dedup and reflink doesn't seem to
> be a problem because it can't be done with encrypted extents anyway.
>

Re: Btrfs native encryption

[Chris Murphy]

On Sun, Apr 26, 2020 at 8:25 AM Mark Harmstone <mark@harmstone.com> wrote:
>
> Last thing I heard was that Omar Sandoval at Facebook was looking into it. I never heard anything back about my patches, though.

I think the biggest difficulty with that patchset isn't as much the
patchset, but the bandwidth of people who can review it. It was a
complex patchset and didn't use fscrypt. (For reasons that are
explained, but then also at least originally the Btrfs maintainers
wanted to initially implement an fscrypt/VFS approach. Maybe it's too
difficult.)

I'm curious whether Omar is working on something and what the time
frame could plausibly be. In the meantime, other approaches are being
explored, based on LUKS encrypted loop mounted files, as in
https://systemd.io/HOME_DIRECTORY/

Btrfs has advantages here, including asynd discards and online fs
resize, in case someone wants to attempt to manage the ensuing fantasy
of sparse backing files. The loss of dedup and reflink doesn't seem to
be a problem because it can't be done with encrypted extents anyway.

-- 
Chris Murphy

Re: Btrfs native encryption

[Mark Harmstone]

Last thing I heard was that Omar Sandoval at Facebook was looking into it. I never heard anything back about my patches, though.

Mark

On 26/4/20 3:14 pm, Nikolay Borisov wrote:
>
> On 26.04.20 г. 16:54 ч., Neal Gompa wrote:
>> Hey,
>>
>> I was looking into encryption in filesystems (for supporting sane full
>> disk encryption), and I noticed that there was some work last year on
>> this: https://lore.kernel.org/linux-btrfs/20190109012701.26441-1-mark@harmstone.com/
>>
>> What is the current state of this work? Is it just the same as back
>> then, or has there been changes?
> No changes, btrfs currently doesn't support encryption.
>
>> Best regards,
>> Neal
>>

Re: Btrfs native encryption

[Nikolay Borisov]

On 26.04.20 г. 16:54 ч., Neal Gompa wrote:
> Hey,
> 
> I was looking into encryption in filesystems (for supporting sane full
> disk encryption), and I noticed that there was some work last year on
> this: https://lore.kernel.org/linux-btrfs/20190109012701.26441-1-mark@harmstone.com/
> 
> What is the current state of this work? Is it just the same as back
> then, or has there been changes?

No changes, btrfs currently doesn't support encryption.

> 
> Best regards,
> Neal
> 

Btrfs native encryption

[Neal Gompa]

Hey,

I was looking into encryption in filesystems (for supporting sane full
disk encryption), and I noticed that there was some work last year on
this: https://lore.kernel.org/linux-btrfs/20190109012701.26441-1-mark@harmstone.com/

What is the current state of this work? Is it just the same as back
then, or has there been changes?

Best regards,
Neal

-- 
真実はいつも一つ！/ Always, there's only one truth!