EXT4 Might Work On Transparent Encryption Support

[phoronix]

Phoronix: EXT4 Might Work On Transparent Encryption Support

Besides Facebook preparing to roll-out Btrfs deployments and Tux3 could soon be mainlined into the Linux kernel, an encryption feature may be added to the EXT4 file-system...

http://www.phoronix.com/vr.php?view=MTY0NTM

[Pajn]

I can't see any reason for this over LUKS.
For file-systems like ZFS and Btrfs yes, but EXT no.

[DeepDayze]

I can't see any reason for this over LUKS.
For file-systems like ZFS and Btrfs yes, but EXT no.

Why not let the filesystem do the heavy lifting and let LUKS just handle the processing of encryption keys/passphrases? With a LUKS-aware transparent encrypting fileystems could make it simple to implement full disk encryption even on currently unencrypted partitions.

[Rexilion]

I can't see any reason for this over LUKS.
For file-systems like ZFS and Btrfs yes, but EXT no.

That was my initial thought as well. But in fact, LUKS is another FS to support encryption. This is odd, since BTRFS is already designed to handle the block layout on a disk. You are practically throwing that away by using LUKS which does that again. Hence, quite some overhead is incurred and you get to throw away many features of BTRFS.

But this is just my heavily uninformed and uneducated opinion about the subject.

EDIT: I guess, in the end, you would want to use ecryptfs instead of LUKS. That way, integration won't be needed.

[jaxxed]

I am surprised that they are the first to talk about it

I am really surprised that the (open)ZFS and BTRFS guys were not in there first. I guess it has really just been a matter or priorities (get it stable first but with today's security and privacy discussions, disk encryption should be a higher priority.

Using LUKs with ZFS and BTRFS is not great for the perfomance/stability, but it is also a pain for the user in any multi-disk case. You have to have separate LUKS paritions, and end up repeatedly entering LUKS passhrases.

[Brane215]

how is crypto within fs meant to work ?

I mean, is it meant to cryptoprotect whole FS or on dir and file basis ?

[zxy_thf]

I mean, is it meant to cryptoprotect whole FS or on dir and file basis ?

I don't see the point to replace full-disk encryption(luks) with fs-level encryption (e.g. eCryptfs). They are two different things.
As we can see, MS Windows supports the both; NTFS has supported EFS for a while (since 2000?), and they still introduced BitLocker in Vista.

In most cases fs-level encryption only protects the content of files, but not the metadata of files. For security reasons I prefer full-disk encryption, esp. with AES-NI hardware it's nearly free.

[Tobu]

Anything less than whole-disk encryption leaks a lot of information, that sounds like a bad idea.

[Rexilion]

Anything less than whole-disk encryption leaks a lot of information, that sounds like a bad idea.

Then don't put sensitive information in file and directory names. Done.

[Luke]

LUKS can open multiple disks from one passphrase entry

I am really surprised that the (open)ZFS and BTRFS guys were not in there first. I guess it has really just been a matter or priorities (get it stable first but with today's security and privacy discussions, disk encryption should be a higher priority.

Using LUKs with ZFS and BTRFS is not great for the perfomance/stability, but it is also a pain for the user in any multi-disk case. You have to have separate LUKS paritions, and end up repeatedly entering LUKS passhrases.

There are several ways to do this. Cryptsetup supports using a keyfile on the root volume to open the others. It is also supposed to support using an included keyscript that will cache the passphrase just long enough to open all disks. Unfortunately that was broken the last time I tested it.

You can write a custom initramfs script to hold the passphrase in RAM, unlock all disks, overwrite the variable holding the passphrase, then unset it. Be damned careful using any custom code with encryption, because a mistake can give away the store! Example. Suppose you did not unset or overwrite the variable and also did not encrypt your swap partition. You fill your RAM in a video editing session, guess what just got swapped out to disk-your passphrase. Any attacker could run data recovery on your swap and unlock the disk. That's really an amateur mistake, but you get the picture. There are also some games you can play with this if you REALLY know what you are doing (like obfuscated code) to make a "evil maid" attack more difficult.