Page 1 of 2 12 LastLast
Results 1 to 10 of 13

Thread: EXT4 Might Work On Transparent Encryption Support

  1. #1
    Join Date
    Jan 2007
    Posts
    14,911

    Default EXT4 Might Work On Transparent Encryption Support

    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

  2. #2
    Join Date
    Sep 2012
    Posts
    280

    Default

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

  3. #3
    Join Date
    Sep 2007
    Location
    Connecticut,USA
    Posts
    962

    Default

    Quote Originally Posted by Pajn View Post
    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.

  4. #4
    Join Date
    Dec 2012
    Posts
    459

    Default

    Quote Originally Posted by Pajn View Post
    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.

  5. #5
    Join Date
    Sep 2012
    Posts
    15

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

  6. #6
    Join Date
    Jul 2012
    Posts
    142

    Default how is crypto within fs meant to work ?

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

  7. #7
    Join Date
    Mar 2012
    Posts
    119

    Default

    Quote Originally Posted by Brane215 View Post
    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.

  8. #8
    Join Date
    Jun 2012
    Posts
    34

    Default

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

  9. #9
    Join Date
    Dec 2012
    Posts
    459

    Default

    Quote Originally Posted by Tobu View Post
    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.

  10. #10
    Join Date
    May 2013
    Posts
    556

    Default LUKS can open multiple disks from one passphrase entry

    Quote Originally Posted by jaxxed View Post
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •