See encrypting file systems for a run-down on why encrypt a file system and general theory etc. There are lots of ways you can do this and lots of levels at which to do it.
Downside: you need to type 2 passwords to log in, the hard drive decrypt key, plus the user key. fscrypt doesn’t have this problem; I can log in and use my keychain to decrypt specific user data. But on the other hand if my whole disk (well, at least the swap disk) is not encrypted I am vulnerable to people sniffing the encryption keys from my swap file, so this method is convenient for my attackers as well as me.
Encrypting the whole disk is probably better in the sense that if it is stolen it will be hard to crack it. Both methods are vulnerable to evil maid attacks where someone installs a key-logger on your computer while you are out to lunch.
I probably want to go with LUKS because there is less for me to mess up in that the automatic installer configures it for me, and just deal with the horrible double-password situation.
Filesystem stacked encryption
Ideally you want magical transparent encrypted disks which decrypt when they log in. There are lots of user-space encryption methods you could use.
Normal files full of garbled encrypted stuff that magically turn into real data if you enter the passphrase.
Is it worth trying FUSE alternatives,
or will they simply be too slow?
encfs was considered insecure in a
famous security audit.
It is still considered insecure by Ubuntu in 2019; I’m unclear if the
later versions of encfs fix that.
fscrypt has also been
I’m not sure where it fits in this hierarchy.
Note that file sync app rclone
can encrypt files in
local mode and
mount the encrypted FS,
albeit with some restrictions.
That might be a convenient way of doing things, since everyone should always
rclone installed just in case, although it might not be well optimized
for this use case.
All these options are free and simple.
If you do this you probably want to also have your swap memory encrypted in case your computer gets taken by the star chamber, but this requires, AFAICT, kernel-level disk encryption of the swap (see below) which, with things as they currently are, means you still need to have a fancy passphrase to decrypt the machine and thus have an extra password to forget.
seems to be a popular whole-partition encryption solution for Linux, working on top of
dm-crypt. Possible still
messy for the boot partition
but otherwise fine if you like full disk encryption.
This is the default for Ubuntu now, and it works smoothly except that you need
to type in a password every time your boot the machine, and that password
must be long and difficult.
See also Veracrypt, which will do this plus bonus extra-crazy tinfoil hat stuff, and has the advantage of working on windows and macOS.
If you are using LVM with encryption there are a couple of layers to deal with at once and I get the various steps in the intricate dance confused.
The best how-to guides for fiddly I found were the following.
- Debian encrypted LVM.
- Ubuntu Updated Full Disk Encryption howto, which also discusses how to handle some shortcomings in the installer.
- Ubuntu guide to resizing encrypted partitions
NB if you are partitioning your entire disk the installer will probably take care of it. It does for Ubuntu. The HOWTOs are only in case of dual-booting Windows.
When my laptop goes to sleep is encrypted data safe?
Unverified advice from LawrenceC suggests that the risk calibration runs as follows
Full disk encryption, by necessity, needs the key in RAM to encrypt/decrypt data in real time.
- Firewire has a DMA like mode that basically allows one to scan the entire RAM of the system. Full disk keys may be recovered from a target system’s RAM if it’s connected via Firewire to a host running the right software and the target system has a Firewire driver that supports this. Your system is vulnerable to this if it is locked. I’m not sure if it’s possible to Firewire-read your RAM while it is asleep.
- If your system is hibernating, all RAM is dumped to a hibernation file before power off. I believe Truecrypt marks pages of its driver somehow to prevent this, but as long as you keep the hibernation file on an encrypted volume you should be safe.
- DRAM takes a while to decay after power off. Theoretically it’s possible for an adversary to remove the RAM from your system, possibly spray it with canned air to lower the temperature and lengthen the decay rate, and put it in a system or tool that scans the RAM and extracts the keys from there. It also may be possible to power cycle your system, boot off of a live CD, and recover the keys from RAM that way.
If the RAM is powered off and has decayed sufficiently, it’s not possible to get keys from it, and your encrypted data is safe in this situation.
Of course the first and third items are tinfoil-hat level stuff, but to prevent against it you should power your system down completely when you are not using it, and run
Memtest86+or your system diagnostics to clear RAM. At least one security-focused Linux distribution does this before power off, I can’t think of the name of it.
More esoteric workarounds are listed the security stack exchange, which lead one to think there might be other unadvertised tricks to get into a locked encrypted machine, and some things you should check your OS has done correctly.
So, depends on your threat profile. An option for the paranoid is to set the machine to hibernate instead of sleeping. However, this does not clear the RAM per default; that would be wise as well for a sufficiently paranoid person.