Experimental Patches Updated Working On FSCRYPT Encryption For Btrfs

[phoronix]

Phoronix: Experimental Patches Updated Working On FSCRYPT Encryption For Btrfs

While the Btrfs file-system has many advanced features like transparent file-system encryption and built-in RAID, at the moment it lacks native file-system encryption but there are patches that continue to be worked on that aim to provide such functionality...

https://www.phoronix.com/news/Btrfs-FSCRYPT-Encryption-RFC-v2

[hamishmb]

Seems like a good thing to have to help btrfs compete.

[Girolamo_Cavazzoni]

Michael there’s a logical error in the first sentence:

While the Btrfs file-system has many advanced features like **transparent file-system encryption and built-in RAID, at the moment it lacks native file-system encryption** but there are patches that continue to be worked on that aim to provide such functionality.

[Michael]

Michael there’s a logical error in the first sentence:

Whoops meant compression, thanks.

[reza]

Thanks to people who are working on fscrypt and obviously not to minimize or devalue their work, but a genuine curiosity: is this duplication of effort? I would have preferred to have all these efforts be put into one project instead of one on fscrypt direction and the ther LUKS/dm-encrypt.

Is there really no other workaround for btrfs to benefit from LUKS/dem-crypt natively/seemlessly? What's the advantage of this effort over btrfs + dm-crypt?

[nadir]

Is there really no other workaround for btrfs to benefit from LUKS/dem-crypt natively/seemlessly? What's the advantage of this effort over btrfs + dm-crypt?

LUKS and fscrypt work on completely different levels. With luks you create an encrypted partition and then put ordinary btrfs partitions on top of it. As far as btrfs is concerned, there's nothing extraordinary happening in this scenario. You can put any other fs on top of luks if you want.

With fscrypt btrfs knows about and is managing the encryption via fscrypt, so the implementations don't really have much in common at all. If you're an outsider without the decryption key a luks partition is just a bunch of random data whereas with with fscrypt you'll have access to some amount of metadata, so it's also a different level of protection.

[oleid]

What's the advantage of this effort over btrfs + dm-crypt?

I see potential benefit in "having one layer less" as it simplifies installation of Linux (if you do it manually and don't have an installer which does the heavy lifting).
Having one layer less could also improve reliability in power-loss situations if you have no battery backup. And finally, in btrfs managed RAID setup fewer data has to be encrypted as the encryption happens inside btrfs. If you have the encryption in block layer is has to run per block device. For me the additional overhead is no problem, though, as AES is insanely fast if your CPU supports it. For other encryption algorithms, however, the gain is probably nice.

[sinepgib]

What's the advantage of this effort over btrfs + dm-crypt?

There are some. First, it tends to be somewhat faster, at the price of not encrypting some metadata (IIRC you can know how many files a folder has and their sizes, but not much more), it works at the folder level (it can be seen as a feature or the lack of one, depending on your use case), it makes it easier to encrypt the home for several users of a shared machine in a way nobody can access anyone else's while not having to create a partition for each, with all it implies (namely, wasted space due to a lack of sharing), in the same lines it allows non-encrypted roots when you don't care about people looking just at config files while being able to use a single big partition, saving you from typing your password twice as well (just let the computer boot and log in).
It's just different, not necessarily better or worse but it covers different use cases. It competes more with the likes of eCryptfs than with dm-crypt.
Personally, I prefer the fscrypt approach and this is a welcome change for my at-some-point migration from F2FS.

[yump]

(IIRC you can know how many files a folder has and their sizes, but not much more),

It should be said that knowing that is knowing a whole hell of a lot. For example, if embarrassing secret documents were leaked to the press and partially published, it could be used to prove that your disk contains a full copy. Even a single file could be identified that way, if if is large enough for the size to be almost certainly unique.

As long as that kind of metadata is exposed, fscrypt seems to only be a good choice for protecting data that is either small and self contained, or that is created locally and never leaves the machine. To be fair, that's enough for session cookies, password databases, PGP keys, and the like, so it handles stolen devices decently well.

[sinepgib]

It should be said that knowing that is knowing a whole hell of a lot. For example, if embarrassing secret documents were leaked to the press and partially published, it could be used to prove that your disk contains a full copy. Even a single file could be identified that way, if if is large enough for the size to be almost certainly unique.

Well, everything depends on who the expected attacker is and what you're trying to protect. If you're that much of a public figure you'd rather have a scheme with plausible deniability in place. Besides, there's no way to prove your disk contains a full copy because the encryption key is unique and sizes are not enough data to displace reasonable doubt.

As long as that kind of metadata is exposed, fscrypt seems to only be a good choice for protecting data that is either small and self contained, or that is created locally and never leaves the machine. To be fair, that's enough for session cookies, password databases, PGP keys, and the like, so it handles stolen devices decently well.

Or, you know, pretty much anything not illegal. If you're not a high profile target you are probably fine with protecting from regular burglars and not much more.