9

BtrFS should support this really, but it doesn't. So ECryptFS looks like it will fill the gap. The only thing is, how would I layer compression on top of this?

Reasons for compression on top of encryption:

  • intentionally, the converse (encryption on top of compression) doesn't compress, because encryption ideally tries to make the ciphertext indistinguishable from random data;
  • encryption of denser information is more secure.

I'm looking for a filesystem-level solution such that files can be encrypted with different keys as appropriate (such as for users/groups) on an ad-hoc basis (i.e. can be changed without major reconfiguration that you have with block-level encryption).

James Haigh
  • 719
  • 2
  • 7
  • 16
  • 2
    It sounds like you want encryption on top of compression, not compression on top of encryption! For example, to the first point on the list, you actually *want* to compress the plaintext, not the ciphertext. – Celada Feb 17 '15 at 12:15
  • @Celada: Well it depends which way you look at it; I'm looking at it from the top downwards with the drive at the bottom. – James Haigh Feb 17 '15 at 12:19
  • Yeah, so don't you want the disk at the bottom, then on top of that (optionally) a partition, then a base filesystem, then the compression on top of that, and topmost of all, the encryption with ECryptFS? I might be experiencing a visualization/geometry fail here...(?) – Celada Feb 17 '15 at 12:23
  • @Celada: No, that wouldn't compress. The ‘plaintext’ (files) comes in from the top. Compression must happen first, then encryption, then BtrFS puts it wherever it does in the partition, etc.. – James Haigh Feb 17 '15 at 12:26
  • .......and my visualization failure is plainly manifest. It must be getting too late. Forget I said anything. – Celada Feb 17 '15 at 12:29
  • I think I'm similarly confused as Celada. If we for a moment ignore the attempt at vertical likeness, are we in agreement that compression must happen first, follow by encryption? One can't meaningfully compress encrypted data, since, as you point out in the question, it's indistinguishable from random data. – user50849 Feb 17 '15 at 13:07
  • 2
    If you want compressed encrypted files, and you don't want to manually create `.gz` or `.xz` files and then encrypt them, a good solution might be an encrypted dm-crypt/LUKS container, formatted with a compressing filesystem like btrfs. LUKS should be able to use multiple keys and *"can be changed without major reconfiguration"* you're concerned about, but then the LUKS container is a large fixed size, hmmm. I've noticed a disappointing lack of compressing filesystems... ntfs & btrfs. Or there's squashfs but it's read-only. – Xen2050 Feb 17 '15 at 14:43
  • 2
    Seriously, I think some people need to read questions a little more carefully. It's well-known that compression must happen before encryption. Dm-crypt/LUKS is block-level, which I specifically don't want, and isn't even supported by GParted. It is definitely not ad-hoc; you'd literally have to resize and move partitions each time you wanted to change security boundaries (users/groups/etc.) and you'd be stuck with quotas. Without support by GParted, or some other easy-to-use tool, it means following a [complicated process](https://help.ubuntu.com/community/ResizeEncryptedPartitions) each time. – James Haigh Feb 17 '15 at 15:24
  • @JamesHaigh That page you link is pretty hilarious. That's pretty much the hardest possible way I could even imagine someone trying to do it. They tell you to reboot for some reason. They also tell you to resize the partition instead of just creating a new one or creating the PV directly on the LUKS container to begin with. I think this may be why you're confused. – Bratchley Feb 17 '15 at 15:36
  • You may want to compress files to save space, but not for security. Compressing data before encrypting it is actually *less* secure. (Your statement that “encryption of denser information is more secure” only applies to prehistorical encryption methods, not to methods invented since the 1970s.) Encryption leaks the (approximate) size of data, and the size of compressed data is affected by the content. This is the basis of the famous [CRIME](http://en.wikipedia.org/wiki/CRIME) attack, for example. – Gilles 'SO- stop being evil' Feb 17 '15 at 22:16
  • 1
    Encryption of dender information is not more secure, it does not affect it. Also be aware that Ecryptfs encrypts files independently, leaking file sizes and directory structure. – ArekBulski Oct 27 '15 at 23:11
  • Why not just use Btrfs on top of LUKS? – damian101 Sep 08 '20 at 14:39

2 Answers2

0

It seems that only approach left is stacking a compressing filesystem on top of encrypting filesystem. Here are few options, but I do not have hands on experience with them:

I doubt that you can select compression or encryption per file. Btrfs is supposed to offer that but reality is probably far from it. Just like it was supposed to have RAID5 years ago.

ArekBulski
  • 443
  • 2
  • 15
0

You've to embed(mainly in superblock private info field) input to compression file system in some database file which is executed when compress file system is mounted on top of encryptfs(using -o option for mount time argument passing). It'll be stackable file system acting on incoming file read/write request as per some predefined mechanisms in file system methods.

Suppose certain files are to be compressed with certain algorithm, this must be figured out by the read/write methods which you will write in compressfs/main.c and file.c etc. Write user level code implementing ioctl to update functioning of this compression file system such as adding/removing/listing algorithms supported by writing to that database which you ported during mount.

Vishal Sahu
  • 273
  • 1
  • 7