On Mon, 19 Sep 2016 14:08:06 -0400, Zygo Blaxell wrote:
> On Sat, Sep 17, 2016 at 06:37:16AM +0000, 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 files and directories stored below the target
>> > directory. Each individual file is encrypted with its own key, which
>> > is derived from the master key and a per-file random nonce value
>> > (which is stored in an extended attribute attached to the file's
>> > inode). File names and symbolic links are also encrypted.
> Probably the simplest way to map this to btrfs is to move the nonce from
> the inode to the extent.
I agree. Mostly, I was making a point about how the ext4/VFS code (which
_does_ put it on the inode) can't just be transported over to btrfs
unchanged, which is what I read Dave Chinner as advocating.
> Inodes aren't unique within a btrfs filesystem, extents can be shared by
> multiple inodes, and a single extent can appear multiple times in the
> same inode at different offsets. Attaching the nonce to the inode would
> not be sufficient to read the extent in all but the special case of a
> single reference at the original offset where it was written, and it
> also leads to the replay problems with duplicate inodes you pointed out.
> Extents in a btrfs filesystem are unique and carry their own attributes
> (e.g. compression format, checksums) and reference count. They can
> easily carry a reference to an encryption policy object and a nonce
> Nonces within metadata are more complicated. btrfs doesn't have
> directory files like ext4 does, so it doesn't get directory filename
> encryption for free with file encryption. Encryption could be done
> per-item in the metadata trees, but in the special case of directories
> that happen to the the roots of subvols, it would be possible to encrypt
> entire pages of metadata at a time (with the caveat that a snapshot
> would require shared encryption policy between the origin and snapshot
Encrypting tree values per-item is actually one of the best arguments in
_favor_ of nonce-misuse-resistant AEAD. Its security notion is very, very
If a (key, nonce, associated data, message) tuple is repeated, the only
data an attacker can discover is the fact that the two ciphertexts have
the same value (a one-bit leak).
In other words, if you encrypt each value in the b-tree with some key,
some nonce, use the b-tree key as the associated data, and use the value
as the message, you get a _very_ secure system against a _very_ wide
variety of attacks - essentially for free. And all _without_ sacrificing
flexibility, as one could use distinct (crypto) keys for distinct (b-
(You still need something for protecting the _structure_ of the B-tree,
but that's a different issue).
> This is what makes keys at the subvol root level so attractive.
>> So there isn't quite a "subvol key" in the VFS approach - each
>> directory has a key, and there are derived keys for the entries below
>> it. (I'll note that this framing does not address shared extents _at
>> all_, and would love to have clarification on that).
> Files are modified by creating new extents (using parameters inherited
> from the inode to fill in the extent attributes) and updating the inode
> to refer to the new extent instead of the old one at the modified
> offset. Cloned extents are references to existing extents associated
> with a different inode or at a different place within the same inode (if
> the extent is not compatible with the destination inode, clone fails
> with an error). A snapshot is an efficient way to clone an entire
> subvol tree at once, including all inodes and attributes.
There is the caveat of chattr +C, which would need hard-disabled for
extent-level encryption (vs block level).
> Inode attributes and extent attributes can sometimes conflict,
> especially during a clone operation. Encryption attributes could become
> one of these cases (i.e. to prevent an extent from one encryption policy
> from being cloned to an inode under a different encryption policy).
That is a good approach.
>> > 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
>> 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
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html