No announcement yet.

EXT4 fscrypt vs. eCryptfs vs. LUKS dm-crypt Benchmarks

  • Filter
  • Time
  • Show
Clear All
new posts

  • EXT4 fscrypt vs. eCryptfs vs. LUKS dm-crypt Benchmarks

    Phoronix: EXT4 fscrypt vs. eCryptfs vs. LUKS dm-crypt Benchmarks

    Given the recent advancements of the EXT4 file-system with its native file-system encryption support provided by the fscrypt framework, here are benchmarks comparing the performance of an EXT4 file-system with no encryption, fscrypt-based encryption, eCryptfs-based encryption, and a LUKS dm-crypt encrypted volume.

  • #2
    All hail LUKS!


    • #3
      What's the encryption method used though? AES is accelerated on Skylake CPU, when using LUKS + dmcrypt, so that might have played a big part in better performance.

      Also, do they all use the same encryption algo or different ones?


      • #4
        ZFS supports native encryption in the development branch.


        • #5
          I run 256-bit AES for LUKS system and swap, to protect the system keys etc from 3rd party acess, and 256-bit blowfish for eCryptFS home folders to protect the users from each other after the system is booted. There's still some danger in shared /tmp, Xorg, shared kernel vulnerabilities, USB devices... but its pretty good for a household of, at worst, white-hat hackers who just want anti-pilferage-level privacy.

          eCryptFS is about 75% the performance of LUKS and LUKS is hard to distinguish from bare metal. The swap is the one that really makes a difference when its comes to speed.

          I use blowfish for eCryptFS only because it is a different cipher than AES, so if one or the other is broken I still have some level of privacy left. I also chose blowfish because it allowed 56-byte keys, but I just use a 32-byte key... in reality typing 56 keys blind without error is just too hard for most of us. I really wish the password entry field wasn't obfuscated. I almost never want it obfuscated, it's a bigger risk because it's obfuscated, because that just makes it harder to use a longer, more secure passphrase. I get that obfuscating it can help when display physical security is a risk, but making that assumption 100% of the time against the wishes of the user is a bad design decision.
          Last edited by linuxgeex; 18 June 2018, 04:30 AM.


          • #6
            i always had, and still have, the opinion that encrypt at least the user data is a must have feature. for convenience i always used ecryptfs without issues, the main reasons are:
            1- ability to acrivate it after installation
            2- ability to activate it only for some specified folders/users/home folders and have different encryption keys
            3- it doesn't need the password at boot time like liks full disk encryption do

            of course i know that talking about performance is the worst, but for me at today is the most flexible.
            about the fact that in ubuntu 18.04 Canonical removed the encrypt home user during installation feature, does anyone has some information? on my ubuntu 18.04 installation i tried to install ecryptfs after installation and then i migrated my home to encrypted... i'm using i since weeks and never encoutered problems... so why canonical removed the feature?
            the only thing i havn't activated encrypted swap.... because i don't need it....