Announcement

Collapse
No announcement yet.

The Performance Impact Of Linux Disk Encryption On Ubuntu 14.04 LTS

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    does Ubuntu still NOT use

    PCRYPT, the 3-way and other optimized encryption ciphers/algorithms ? (last time checked with 13.10 it didn't)

    Comment


    • #12
      How will these option work on a btrfs filesystem? Considering snapshoting and the likes

      Comment


      • #13
        Did you ever use PTS? It puts everything in the home dir (.phoronix-test-suite).
        ## VGA ##
        AMD: X1950XTX, HD3870, HD5870
        Intel: GMA45, HD3000 (Core i5 2500K)

        Comment


        • #14
          typo: performace

          Comment


          • #15
            Why is eCryptfs so slow (or alternatively LUKS faster)? At first I thought it was that the decryption wasn't being hardware accelerated, but according to https://wiki.archlinux.org/index.php/Disk_Encryption, it has the feature. Is the file system implemented in eCryptfs that bad? I can almost believe it from the compile benchmark, but I'm not familiar with this space at all.

            Comment


            • #16
              Originally posted by FourDMusic View Post
              Why is eCryptfs so slow (or alternatively LUKS faster)? At first I thought it was that the decryption wasn't being hardware accelerated, but according to https://wiki.archlinux.org/index.php/Disk_Encryption, it has the feature. Is the file system implemented in eCryptfs that bad? I can almost believe it from the compile benchmark, but I'm not familiar with this space at all.
              Maybe it's an older version? Or the Ubuntu build doesn't have that feature enabled.

              Comment


              • #17
                Originally posted by jakubo View Post
                so can it be worked around by creating a home partition? And does Full disk mean full disc or does it mean full partition?
                Full disk does always mean full partition.

                Originally posted by FourDMusic View Post
                Why is eCryptfs so slow (or alternatively LUKS faster)? At first I thought it was that the decryption wasn't being hardware accelerated, but according to https://wiki.archlinux.org/index.php/Disk_Encryption, it has the feature. Is the file system implemented in eCryptfs that bad? I can almost believe it from the compile benchmark, but I'm not familiar with this space at all.
                eCryptfs does encrypt files where full disk encryption encrypts a bytestream so it has a lot less to deal with,
                and can store the stuff right away where eCryptfs have to hand it back to the FS.

                Comment


                • #18
                  Performance, security both favor full disk encryption

                  I had a computer full of encrypted data defeat police forensics after a 2008 raid on my house, so I always encrypt any computer that will ever work with my photos, videos, or other material. I won't even go online with an unencrypted machine except by running the browser entirely in RAM the way a live disk does it.

                  The most important thing in encryption is security, you need to encrypt or keep in RAM anything that could ever hold sensitive information. Speed is secondary, but yes, encrypting 4+ GB of video files into a netbook on the road does get painfully slow. Now I find that had I used ecryptfs it might have been impractically slow to the point of forcing me to keep the files on the unencrypted camera cards until I could reach an encrypted desktop. On older Atom netbooks, a big encrypted file transfer job can use almost all the CPU capacity, on a multicore desktop even moving data from an SSD to a RAID won't. Especially slow on the Atom is moving files from an encrypted hard drive to an encrypted flash drive.

                  A home directory only system is a security issue in itself as well. This is especially bad if you are using any KDE applications that stash private information in /var/tmp. I don't know if any still do, but I heard years ago that KDE was even stashing emails there. Also remember that encrypted partitions cannot easily be written to by an attacker with offline physical access.

                  Comment


                  • #19
                    Originally posted by raineee View Post
                    I don't use Ubuntu & friends, but I would assume that the comment regarding to /tmp is moot; /tmp is ordinarily a tmpfs these days.
                    Probably, but the spirit of the comment also applies to places like /var/tmp and /var/log. If user FOO writes to tempfs, does anything prevent user BAR from reading it besides -r perms? Can root read it?

                    For me, the bigger question is whether to use full-disk-encryption, or simply encrypt the VM using Fusion (or whatever HVisor the customer happens to use).

                    Comment


                    • #20
                      What encryption algorithms do these use? If they're compatible, can they use Intel's AES-NI to accelerate the encryption/decryption or was it already enabled?

                      Comment

                      Working...
                      X