If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Comment

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.

Comment

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.

Comment

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.

Comment

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.

Comment

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.