btrfs: add encryption feature
btrfs: add encryption feature
cross-posted from: https://lemmy.ml/post/1840134
This is a changeset adding encryption to btrfs. It is not complete; it does not support inline data or verity or authenticated encryption. It is primarily intended as a proof that the fscrypt extent encryption changeset it builds on work. As per the design doc refined in the fall of last year [1], btrfs encryption has several steps: first, adding extent encryption to fscrypt and then btrfs; second, adding authenticated encryption support to the block layer, fscrypt, and then btrfs; and later adding potentially the ability to change the key used by a directory (either for all data or just newly written data) and/or allowing use of inline extents and verity items in combination with encryption and/or enabling send/receive of encrypted volumes. As such, this change is only the first step and is unsafe. This change does not pass a couple of encryption xfstests, because of different properties of extent encryption. It hasn't been tested with direct IO or RAID. Because currently extent encryption always uses inline encryption (i.e. IO-block-only) for data encryption, it does not support encryption of inline extents; similarly, since btrfs stores verity items in the tree instead of in inline encryptable blocks on disk as other filesystems do, btrfs cannot currently encrypt verity items. Finally, this is insecure; the checksums are calculated on the unencrypted data and stored unencrypted, which is a potential information leak. (This will be addressed by authenticated encryption). This changeset is built on two prior changesets to fscrypt: [2] and [3] and should have no effect on unencrypted usage. [1] https://docs.google.com/document/d/1janjxewlewtVPqctkWOjSa7OhCgB8Gdx7iDaCDQQNZA/edit?usp=sharing [2] https://lore.kernel.org/linux-fscrypt/cover.1687988119.git.sweettea-kernel@dorminy.me/ [3] https://lore.kernel.org/linux-fscrypt/cover.1687988246.git.sweettea-kernel@dorminy.me
Is there a major performance benefit to encryption using LUKS over this?
Or is this more useful for like, encrypting a single directory of a filesystem?
I’ve never quite understood the impetus for each filesystem handling encryption rather than doing it at the block layer
Possibilities at the block layer are generally quite limited since it only has limited means to work with. It's very low-level. For example, it is not possible to do authentication in LUKS. An attacker can't read the data but they can modify it; undetected.
You need to stack another layer on top and I'm not sure that's even a thing.
The patch mentions that authenticated hashes aren't supported yet either but with effectively limitless metadata to work with, it's at least possible to do.
Per-directory/subvolume encryption is also a useful feature. You could encrypt the root fs which generally does not contain sensitive information using a key in TPM but then require a password to unlock the user's home. That's basically how it works in Android and it builds on top of fscrypt.