Experimental Patches Updated Working On FSCRYPT Encryption For Btrfs

[yump]

Precisely because it doesn't scale you wouldn't expect them to use it unless you were a very high profile target. I tend to assume (possibly wrongly) that people posting in Phoronix aren't those.

That attack doesn't scale. But slurping the directory listings off of every laptop that goes through customs does. Ditto for every device collected incidental to an arrest. NVMe is very fast. On my machine, with caches cold, this command takes a little over 3 seconds and produces a little over 2 MB of data:

sudo find /home -xdev -exec stat -c'%b %n' '{}' + | zstd -10 | pv >/dev/null

The complicated and expensive attack was brought up to suggest that the potential metadata weaknesses of fscrypt don't matter, because a sufficiently resourced adversary could get your data anyway. However, it's still worthwhile to force such adversaries to expend resources every time they want to get the average user's data, even if you don't consider frustrating government surveillance a positive good on its own.

If there's a known weakness in the disk encryption scheme that everyone uses, and that weakness is sufficient for the state's investigatory purposes, they will use that weakness, and either keep the arsenal of zero-days secret, or put less effort into finding them in the first place. But the blackhats and foreign intelligence services will not sleep. If, instead, known weaknesses are fixed, then state actors have to find new weaknesses, and the Linux ecosystem benefits from a continual trickle of free government-sponsored security research.

If you don't remove the low-hanging fruit from the tree, you won't know if the canopy is rotten.

I'd argue if you're able to talk your way out of that, you probably can do the same with weaker encryption schemes. For something as quick as grabbing you while crossing the border the "attack" would be forcing you to write your password, not comparing metadata to check if you have some leaked data IMO, which is what triggered this discussion. At that point, what matters is data and how to decrypt it. That part is just as hard with fscrypt as it is with dm-crypt, because both require the same from you.

For one, forcing you to write your password (or failing to force you) can't be done without your participation or knowledge. Collecting metadata can. For two, don't think of it as just, "checking if you have leaked data". Think of it as tracking the distribution of the data you have: where it came from, and where it ends up. If it ever pops up on the internet in plaintext, they can guess exactly what it was.

I don't know about you, but the last panel does seem to imply that if your company fires you and blacklists you it's as bad as a State censoring.

Yeah, what I linked was actually an edit meant to hilight the problems with the original.

The one about standards and 538 are spot on IMO. Covering a different use case is not the same as trying to replace the other 14 standards, and that's where it really matters to create a new solution.

The problem with the one about standards and 538 is that they both seem to get used a lot to sneer at the idea that something could be made better.

[polarathene]

Consider a ripped CD compressed to flac. About 15 files, about 25 MB each. If the last two bits of the file size, quantized to 4KiB, are approximately random (so -+ 8 KiB), the chance that the directory containing a CD rip has the particular pattern of file sizes that it does, is approximately 1 in a billion. For me this is enough to displace reasonable doubt, and that's only 15 files in a 1-deep directory.

If you're paranoid about such and that concerns you, while you're aware of this issue... then why not obfuscate the concern away?

Compress the folder or files, or use another layer of encryption, perhaps even a container such as a raw .img file that you format a filesystem onto and mount with loopback? Or a VM with virtual disk (basically same thing).

Problem solved? Especially when you hide away the whole folder or mix it in with other contents, where is the problem now? The metadata isn't going to say much now is it? Hardly inconvenient either, especially when it's government documents or similar that you may rarely access, but when you need to is a few clicks away.

[yump]

If you're paranoid about such and that concerns you, while you're aware of this issue... then why not obfuscate the concern away?

Compress the folder or files, or use another layer of encryption, perhaps even a container such as a raw .img file that you format a filesystem onto and mount with loopback? Or a VM with virtual disk (basically same thing).

Problem solved? Especially when you hide away the whole folder or mix it in with other contents, where is the problem now? The metadata isn't going to say much now is it? Hardly inconvenient either, especially when it's government documents or similar that you may rarely access, but when you need to is a few clicks away.

Alternately, keep using dmcrypt+LUKS. Block-level encryption is structurally resistant to metadata leakage, and LUKS's maintainers were so aware of this category of problem that TRIM passthrough is default-disabled just because it might leak information via filesystem block use patterns. Dmcrypt doesn't require extra thought to what might need real security vs nosy-sibling security, and doesn't get in the way of working with the files. (Although keeping extra-sensitive data in a separately-keyed container that is unmounted when not needed is still a good idea.)

What I am specifically trying to avoid is a "disk encryption" scheme that leaks metadata becoming the widely-used default choice, because it weakens herd immunity for everyone. This has already happened to Android.

And keep in mind also what I said at the end of (the on-topic part of) my last post:

For two, don't think of it as just, "checking if you have leaked data". Think of it as tracking the distribution of the data you have: where it came from, and where it ends up. If it ever pops up on the internet in plaintext, they can guess exactly what it was.

[anarki2]

FSCRYPT is way too buggy and a bad approach to a legitimate issue. It causes totally random issues in Docker, Firefox, etc, making it feel like a patchwork.

Key management is a complete mess, to begin with. The userspace utils are very lacking, and sometimes they break compat.

How many more years will it take for Linux to have usable, TRANSPARENT, hassle-free FDE, that doesn't require repartitioning, really?

[sinepgib]

FSCRYPT is way too buggy and a bad approach to a legitimate issue. It causes totally random issues in Docker, Firefox, etc, making it feel like a patchwork.

In which way? I had no issues with it since about 5 years already.

Key management is a complete mess, to begin with. The userspace utils are very lacking, and sometimes they break compat.

That I agree. Only the last time I installed login decryption started working decently, but then fingerprint login doesn't really work out of the box with decryption (I've read systemd-homed does make that simple, but it sounds like too much at the moment).

How many more years will it take for Linux to have usable, TRANSPARENT, hassle-free FDE, that doesn't require repartitioning, really?

If I have to guess, 20 years from now ideally. All the interest in this seems to be coming from Lennart, and everyone knows how "well loved" by the community he is. And now he's not with Red Hat I'm not seeing them forcing it down to anyone.

[ebiggers]

FSCRYPT is way too buggy and a bad approach to a legitimate issue. It causes totally random issues in Docker, Firefox, etc, making it feel like a patchwork.

Key management is a complete mess, to begin with. The userspace utils are very lacking, and sometimes they break compat.

How many more years will it take for Linux to have usable, TRANSPARENT, hassle-free FDE, that doesn't require repartitioning, really?

If you have any feedback about the fscrypt userspace tool, please open an issue at https://github.com/google/fscrypt/issues (or comment on an existing issue if there is one).

Note that the Docker and Firefox issues which you refer to were already fixed years ago.

[EphemeralEft]

If BTRFS must implement RAID, then it should implement encryption as well. But I still think that filesystems should stick to just being a system for files.

It’s also unfortunate that its checksumming is only for BTRFS, because it’s way better than DM-Integrity but can’t be used for anything else.