Re: [RFC] Preliminary BTRFS Encryption

[Zygo Blaxell <ce3g8jdj@umail.furryterror.org>]

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

On Mon, Sep 19, 2016 at 08:01:06PM +0000, Alex Elsayed wrote:
> >> > I don't see how snapshots could work, writable or otherwise, without
> >> > separating the key identity from the subvol identity and having a
> >> > many-to-one relationship between subvols and keys.  The extents in
> >> > each subvol would be shared, and they'd be encrypted with a single
> >> > secret, so there's not really another way to do this.
> >> 
> >> That's not the issue. The issue is that, assuming the key stays the
> >> same,
> >> then a user could quite possibly create a snapshot, write into both the
> >> original and the snapshot, causing encryption to occur twice with the
> >> same key, same nonce, and different data.
> > 
> > If the extents have nonces (and inodes do not) then this doesn't happen.
> > A write to either snapshot necessarily creates new extents in all cases
> > (the nodatacow feature, the only way to modify a data extent in-place,
> > is disabled when the extent is shared).
> 
> As above, note that if encryption is applied to extents rather than 
> blocks, nodatacow becomes a data loss vector (partial write -> AEAD 
> verify failure).

nodatacow is already a data loss vector.  There is already no atomic
update guarantee and no checksums (not even CRC32) on nodatacow extents.
Silent data corruption is an expected outcome.

They are supposed to be used for applications where performance needs
trump data integrity needs on specific files (presumably applications
that provide their own checking or can reconstruct the data).

They could support an unauthenticated dm-crypt-style block level
encryption...if we like writing long security manual pages full of
caveats that nobody ever reads.  It's certainly safer to just prohibit
the combination of nodatacow and encryption.

Someone could implement metadata logging/journalling to make nodatacow
work with checksums, which would make AEAD work with them, but the
overhead would probably negate the performance benefit that makes
nodatacow attractive in the first place.


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