Results 1 to 10 of 13

Thread: EXT4 Might Work On Transparent Encryption Support

Hybrid View

  1. #1
    Join Date
    Jan 2007
    Posts
    15,133

    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
    287

    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
    964

    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
    16

    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
    147

    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
    124

    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
    May 2013
    Posts
    572

    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.

  9. #9
    Join Date
    Oct 2006
    Location
    Israel
    Posts
    600

    Default

    Quote Originally Posted by jaxxed View Post
    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.
    Seems to be distro specific issue.
    At least in Fedora and RHEL/CentOS (Plymouth), the initial password is used to unlock all crypto partitions.
    You get a second prompt only if the initial password fails.

    - Gilboa
    DEV: Intel S2600C0, 2xE52658V2, 32GB, 4x2TB, GTX780, F20/x86_64, Dell U2711.
    SRV: Intel S5520SC, 2xX5680, 36GB, 4x2TB, GTX550, F20/x86_64, Dell U2412..
    BACK: Tyan Tempest i5400XT, 2xE5335, 8GB, 3x1.5TB, 9800GTX, F20/x86-64.
    LAP: ASUS N56VJ, i7-3630QM, 16GB, 1TB, 635M, F20/x86_64.

  10. #10
    Join Date
    Oct 2006
    Location
    Israel
    Posts
    600

    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.
    Unless there's a huge performance win in having FS-level encryption - I fail to see why *any* FS should have its own encryption support.
    Instead of solving security and performance issues in one layer (dm-crypt) you are now forced to solve the same (?) issue across different FS' (ext4-crypt, btrfs-crypt, etc).
    Granted, all FS' can share the same crypto code and implement it differently on disk - but this will be more-or-less the same as improving dm-crypt (which in the case of btrfs COW, may be a hard requirement).

    - Gilboa
    DEV: Intel S2600C0, 2xE52658V2, 32GB, 4x2TB, GTX780, F20/x86_64, Dell U2711.
    SRV: Intel S5520SC, 2xX5680, 36GB, 4x2TB, GTX550, F20/x86_64, Dell U2412..
    BACK: Tyan Tempest i5400XT, 2xE5335, 8GB, 3x1.5TB, 9800GTX, F20/x86-64.
    LAP: ASUS N56VJ, i7-3630QM, 16GB, 1TB, 635M, F20/x86_64.

Posting Permissions

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