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

Thread: The Performance Impact Of Linux Disk Encryption On Ubuntu 14.04 LTS

Hybrid View

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

    Default The Performance Impact Of Linux Disk Encryption On Ubuntu 14.04 LTS

    Phoronix: The Performace Impact Of Linux Disk Encryption On Ubuntu 14.04 LTS

    For any Linux laptop users or those concerned about their data's safety on production systems, I highly recommend utilizing disk encryption for safeguarding the data. However, what's the performance impact like these days? In this article with the current development snapshot of Ubuntu 14.04 LTS on a modern Intel ultrabook we're looking at the impact (including CPU utilization) of using an eCryptfs-based home directory encryption and LUKS-based full-disk encryption on Ubuntu Linux.

    http://www.phoronix.com/vr.php?view=19979

  2. #2
    Join Date
    Jan 2014
    Posts
    13

    Default

    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.

  3. #3
    Join Date
    Jan 2009
    Posts
    464

    Default

    Quote 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).

  4. #4
    Join Date
    Aug 2013
    Posts
    82

    Default

    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?

  5. #5
    Join Date
    Mar 2013
    Posts
    49

    Default

    Quote Originally Posted by guido12 View Post
    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?
    Most likely AES. In the case of dm-crypt/LUKS, it just uses the kernel's crypto API, so it depends on what was enabled with that. I'm not positive, but I think AES-NI would have to be enabled at kernel compile time.

  6. #6
    Join Date
    Aug 2007
    Posts
    6,634

    Default

    Basically the unencrypted /boot partition is itself an attack vector for evil maid attacks, you could use a grub partition or use grub from EFI partition to avoid that. It does not fix the possibilty of EFI rootkits or modfied grub loaders however but changeing the initrd to store the pw after entering it is very easy. As example how to boot that way look at
    http://kanotix.com/files/fix/crypto/
    It is possible to store the pw on the encrypted part but thats optional. If you don't it works as well but you enter the pw twice. If you install with /boot or /boot/efi partition in custom mode while using luks you get the same as Ubuntu with the new installer. I would test it in a VM first...
    http://nightly.kanotix.acritox.com/latest/

  7. #7
    Join Date
    May 2013
    Posts
    557

    Default /var/tmp et all are written to disk

    Quote Originally Posted by russofris View Post
    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).
    On tempfs, content is lost at poweroff, preventing the MSS, FBI or other thieves from reading what was stored there. On the other hand, /var/log and /var/tmp are on disk. If logs were on RAM, you'd lose your logs at every reboot, making some things impossible to diagnose. KDE at least used to store emails in /var/tmp, a serious security issue when /home is encrpyted. A simple workaround for this is to create directories owned by root in /home and bind mount them on /var/tmp, /var/spool (print jobs, etc) and /var/log (records of what you mounted, etc). That's what I did before I switched to encrypting everything but /boot, something I did to reduce the attack surface for an enemy installing malicious software to a powered down machine.

    With only /boot encrypted, there are ways to check post-boot for tampering. You can counter that checking with a smart enough "evil maid" attack, but that requires knowing what you are up against, etc and at that point a BIOS or hardware keylogger gets easier to install. There are of course detection methods and defenses for those as well.

    Do keep in mind I use encryption to foil governmental forensics, if protecting your data from street thieves other than organized crime is your reason for encrypting a computer you may need less security than that required to defeat the FBI and Secret Service and especially less than that needed to defeat the NSA. Speaking of that, if the NSA was ever able to decrypt a randomly picked disk encrypted with AES dropped into their laps, there would soon be stories about US government and military contractors being told not to use AES anymore, for fear of other governments also finding the same crack. As of now they are permitted to use it even for Top Secret stuff.

  8. #8
    Join Date
    Aug 2007
    Location
    Norway
    Posts
    146

    Default

    Quote 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.
    That would be a dangerous assumption. Data in a tmpfs can be swapped out to disk in low memory conditions. If you have an unencrypted swap partition in use, then data from files, which you thought were safely gone from /tmp by the time power was cut, may still be available in raw form somewhere on the swap partition.

  9. #9
    Join Date
    May 2013
    Posts
    557

    Default Unencrypted swap is never safe with encryption

    Quote Originally Posted by oyvind View Post
    That would be a dangerous assumption. Data in a tmpfs can be swapped out to disk in low memory conditions. If you have an unencrypted swap partition in use, then data from files, which you thought were safely gone from /tmp by the time power was cut, may still be available in raw form somewhere on the swap partition.
    This is also true of any encrypted data stored anywhere you may have loaded into RAM and worked on. The key is supposed to be protected from being swapped out, but a bug in memlock combined with using only an encrypted flash drive could theoretically get a key swapped out. On an machine with unencrypted swap, run sudo swapoff -a before mounting any encrypted device
    and power down before using swap again,

  10. #10
    Join Date
    Sep 2012
    Posts
    280

    Default

    Quote Originally Posted by Luke View Post
    This is also true of any encrypted data stored anywhere you may have loaded into RAM and worked on. The key is supposed to be protected from being swapped out, but a bug in memlock combined with using only an encrypted flash drive could theoretically get a key swapped out. On an machine with unencrypted swap, run sudo swapoff -a before mounting any encrypted device
    and power down before using swap again,
    If you use full disk encryption in Ubuntu it will set up an encrypted swap.

Posting Permissions

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