The Cost Of Home Directory Encryption & LUKS Full Disk Encryption On Ubuntu 18.04

[DanL]

The article leaves me wondering how LUKS for the full disk compares to a LUKS home partition.

[linuxgeex]

I wish that Linux distros would put some work into detecting usable TPM and SED hardware. On almost any modern laptop the hardware can manage secure key storage and full disk encryption on its own. There's zero reason to have the CPU encrypting for you on those machines.

That hardware isn't up to the performance required for NVMe or even high-end SATA3 disk bandwidth. Not even remotely close.

[linuxgeex]

Better idea - don't use swap at all. You don't need it now that machines have 16 to 64 gigabytes of RAM.

Or just use a swapfile on your already full-disk-encrypted system. The only real reason to use a swap partition these days is to use a separate swap device. There's no measurable performance improvement using a swap partition, but there's definitely a measurable sysadmin performance improvement from not wasting your time with disk partitioning where it's unnecessary, lol.

[linuxgeex]

Michael What this article doesn't touch is the added security that eCryptfs adds on a multi-user system. On a system with full-disk encryption, anyone who gains access to a system administrator that can access the unlocked, mounted storage volume backing partition via /dev/mapper/ can still access other users' private data. On a system with eCryptfs, even if they have access to the unlocked storage volume they can't read it. Even a user with temporary root can't read the user's private data. They would need to become the user while the user is logged in, or attach to a running user process and hijack it, or trick the user into running a hostile process to either log the authentication process or to provide proxy filesystem access.

I run both LUKS and eCryptfs on my home multi-user systems.

The LUKS uses a key file on a USB storage device that is only present in the system when it boots, effectively emulating TPM, so I'm the only one who can boot the system, and nobody can modify the system while it is offline and I'm not around.

After the system is up, the users are isolated by eCryptfs. That's important because I run different users for my personal browsing, my work, my gf's work, and the device administrator. If my personal user gets hijacked because of something stupid I do, there's still strong isolation from the other users. Ubuntu by default kills all processes from the currently running user when you log out, so as long as I don't log in multiple users at the same time there's zero risk of key exposure or process hijacking by a trojan running as one user attempting to access the other, and there's zero risk of exposure of private data due to direct access to backing storage, even though the shared storage volume is unlocked.

So what this comparison is lacking is a test of the performance with both LUKS and eCryptfs at the same time so people can compare the performance and decide whether the additional isolation is worth the performance loss. TBH I can't tell the difference. It feels every bit as fast with both enabled as with both disabled. For the most part the speed limits I run into are things like my iPhone's speed when syncing files off the phone, or slow USB storage devices like my Lexar S7 256G thumb drive that peaks at 130M/s, and comes nowhere near the speed of the user home folders.

For the compile benchmarks for things like the linux kernel, nobody is going to perform those tasks in their home folder. They're going to build the kernel at /usr/src/linux* where eCryptfs is not in use, so that kernel build benchmark is skewed - eCryptfs will have no impact on those builds whatsoever. Some people working on proprietary software might perform builds of their own personal trees in their home folder because they are relying on eCryptfs to protect their code from prying eyes. Then yes, it would have an impact.

[Kano]

@Michael

The hardware AES support seems pretty good. How about testing the same with the fastest NVME drive you have got?

[franglais125]

..and I've been encrypting only the home folder all these years thinking it'll be faster!!
Thanks Michael, valuable info.

Depends... How do you encrypt it?

[caligula]

https://chrisdown.name/2018/01/02/in-defence-of-swap.html

TLDR: You want swap regardless of the amount of system RAM you have.

Currently the default swappiness is so low that many systems don't really use swap. I have 32 GB of RAM and 20 GB of swap. Guess how much swap is being used when my RAM load is 20GB ? The answer is 120 MB (checked it just now!). That page recommends me to have around 120 MB of swap. I have over 100 times more of it. I'm pretty confident that most users could deal with no swap at all. There's always some mental burden maintaining swap partitions/files. It doesn't really matter if I have 120 MB less filesystem cache available. The difference is so small.

[caligula]

I am suprised that the pro swap article does not make any mention about the usage of swap for hibernation to disk.

Swap is a requirement for that, isn't it? Or are there other ways to achieve that?

It does

"For laptop/desktop users who want to hibernate to swap, this also needs to be taken into account – in this case your swap file should be at least your physical RAM size."

[Zan Lynx]

That hardware isn't up to the performance required for NVMe or even high-end SATA3 disk bandwidth. Not even remotely close.

I'm not sure which hardware you think I meant, but look at, for example, a Samsung 960 Pro NVMe drive. That drive encrypts everything, all of the time, using AES 256. It supports the OPAL standards and from some checking I did online, Samsung is considering a firmware update to add Microsoft eDrive that would let it operate transparently with Bitlocker.

So if Samsung can run AES at 2.5 GB/s I think anyone can.

As you know, TPMs are pretty slow. But their use is for storing and retrieving the key to use for the AES encryption, not to do the AES themselves.

[linuxgeex]

I'm not sure which hardware you think I meant, but look at, for example, a Samsung 960 Pro NVMe drive. That drive encrypts everything, all of the time, using AES 256. It supports the OPAL standards and from some checking I did online, Samsung is considering a firmware update to add Microsoft eDrive that would let it operate transparently with Bitlocker.

So if Samsung can run AES at 2.5 GB/s I think anyone can.

As you know, TPMs are pretty slow. But their use is for storing and retrieving the key to use for the AES encryption, not to do the AES themselves.

Yeah sorry it wasn't clear you were talking about self-encrypting drives. I see that now.

Yeah practically every drive I have owned over the last year has supported TCG Opal, and I've never made use of it because I trust the in-kernel implementation a lot better and the real-world performance impact for relying on the kernel implementation is 1-2%. Also software-defined disks allow slicing up the storage up so that some has encryption and some does not, or even allowing multiple volumes with entirely different keys, which can be super convenient. So that is my own personal answer to your question. As for why distros are not making any attempt to configure SED for users... that probably has to do with timing and is similar to the reasons why many users prefer software RAID over hardware RAID as well.

If you use SED for your boot volume then you need to provide a supported TPM device at boot time to the BIOS/UEFI, or enter a key at the BIOS/UEFI, which is ... distasteful at best... and neither of those options requires distro support - it's just up to you.

If you want to boot from the SED without unlocking it first, then you need an unencrypted partition table with an unencrypted boot volume to boot from. Then things get hairy when you configure the SED (presumably from an initrd) because the partition table is corrupted. So then you need to provide a partition table on a separate device and use MD to linear concatenate the SED with the external partition table image so that you can have a working partition table. Then you can continue mounting filesystems off the combined MD. That implies a minor performance penalty from the MD layer. But the real problem is the system configuration.

I can't see any of the distros going for this, ever. Imagine the average user taking their laptop to a repair center and giving them the key to their SED. The repair center is going to unlock it and find a drive with no working partition table, but they will see a working partition table before they unlock it, so they will simply think the user is on crack. Maybe this would be a good first step in defeating rubberhose cryptanalysis...