Hello.
I was just curious. Suppose you want to install linux with disk encryption (encrypted root file system as well as encrypted swap), and pre-boot authentication (unencrypted /boot) using the old MBR partitioning. The device names could be improved to use UUID's instead, but that's not the point right now. I got two scenarios here:


Scenario A: The system is set up in a way where the main HDD has two partitions on it. The first one is an unencrypted /boot partition, and the second one is a LUKS-encrypted volume. The LUKS volume uses LVM ontop to further divide the *virtual* disk space into two sub-sections. One of them is the root file system, and the other is a SWAP volume. This means the SWAP resides inside the main LUKS-encrypted partion, next to the root file system.

fstab:
crypttab:


Scenario B: The system is set up in a way where the main HDD has three partitions on it. The first one is an unencrypted /boot partition, the second one is a LUKS-encrypted volume containing the root file system (LVM is optional here), and the third one is used for encrypted swap. This means the swap resides outside LUKS volume, and uses its own encryption scheme.

fstab:
crypttab:



What are the advantages and drawbacks of each scenario? Suppose you don't plan to use suspend/hibernation.
The only thing I can think of is that if you are forced to decrypt the drive, with scenario B an adversary won't be able to figure out the contents of the swap because the keys are destroyed with each reboot. The swap on acenario A is preserved.

Thoughts?

I try to avoid the complexity of LVM unless I really need it, and just subdividing a LUKS volume to split off some swap space wouldn't, for me, come anywhere near satisfying that "need" threshold.

I use your 2nd scenario (swap partition randomly encrypted at boot) in combination with /tmp on a tmpfs to ensure that my temporary files cannot be recovered by forensic analysis.

Yeah, I'm setting up btrfs on the root partition, so no need for LVM. Maybe a quick comment for the scenario B, which I decided to use. I encountered a small problem while tinkering with the mount options in crypttab. Hopefully somebody finds this useful. Consider these two entries in crypttab:

(1) cryptswap /dev/disk/by-id/ata-........-part3 /dev/random swap,cipher=aes-xts-plain64:sha512,hash=sha512,size=512
(2) cryptswap /dev/disk/by-id/ata-........-part3 /dev/random swap,cipher=aes-xts-plain64:sha512,size=512

In crypttab do not use an entry like (1)! This will prompt the user to enter a password for the swap partition at boot. The dm-crypt will then fail to set up the swap partition. Clearing the "hash=sha512" option solves this - the line should look like (2).

Regards!

Maybe put on a swap file instead of a partition?
Do you really need swap?

Afaik, swap files are a bit slower than swap partitions. Additionally I'm using btrfs, and a lot of articles suggest that using a swapfile on btrfs will corrupt the filesystem, so it's a no-no. I am unsure whether I need swap, but I read somewhere it is generally a good idea to include a swap partition, because linux uses it for caching idle tasks, etc. I have a laptop with 8GB of ram and a stationary PC with 16 GB of ram.

Although this topic is not about whether or not I need swap. It is about how to encrypt and secure swap.

Regards!


EDIT: I just found out that distros like Xubuntu are having some problems with swap that is configured under scenario B. Sometimes the OS won't boot, but most of the time you get an annoying message on the splash screen about the swap not being ready. I even got a kernel panic once.

Related bug report:
https://bugs.launchpad.net/ubuntu/+s...ux/+bug/798086

I also avoid the extra layer of LVM unless it is absolutely needed. I use the second scenario, indeed, being a bit "paranoid", I usually recommend people encrypt their swap file even if they don't use encryption otherwise as it can potentially hold sensitive data that isn't otherwise stored on the system.

Scenario two should theoretically be faster though for most average users just looking for a little security they're not likely to notice the difference. There should however be no problem with an encrypted swap under scenario two.

LVM does not add complexity. It simplifies disk management.

I suggest scenario A. That is what I have done for years, and I've never had a problem. In fact, I have two different LUKs-encrypted volume groups and I put a logical swap partition on each with priority set in fstab to favor the swap file that is on the volume group that is least active. Also, /home in a different logical volume from /.

I'm curious about this statement:

I have no experience with btrfs. Does it provide it's own logical volume management scheme similar to LVM, or is there something about btrfs that obviates the advantages of using LVM?

I am beginning to wonder if any common encryption is really secure at all. A search the other day for ways to break encryption left me kind of sad. One product claimed to break maybe 23 of the 25 common ones in use by brute force if needed using gpu and cpu and sse. While the key it's self is secure, the brute force attempt doesn't suffer that.
If you can't break it locally they offer supercomputers for such a task at some penny per millions of attempts. Might end up costing you $12.54 to break into NSA.

Subvolumes.


Every encryption can be broken. Eventually.