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).

Improve this question
12
  • 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
    Commented Feb 17, 2015 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
    Commented Feb 17, 2015 at 12:19
  • 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
    Commented Feb 17, 2015 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 each time.
    – James Haigh
    Commented Feb 17, 2015 at 15:24
  • 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
    Commented Oct 27, 2015 at 23:11

2 Answers 2

Reset to default
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.

Improve this answer
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.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .