Best practice for encrypted swap setup

JacoNIX97 · 2025-12-17 08:22:45

Hi everyone.
I'm looking into encrypted swap. My setup right now is a swap partition on an LVM volume inside a LUKS partition. I see on the wiki that the first method suggested (disregarding hibernation as I don't use it) is to use crypttab to create an encrypted virtual swap device to be mounted with fstab. I understand that the advantage comparing it to my current setup is that the encryption key variation renders the swap partition contents unusable between reboots and that enhances privacy as there is no risk of recovering sensitive information from a previous session, while on my setup the key never changes.
Now: I know this may be excessive security, but I'm having fun configuring my new system and want to explore a more secure setup that what I previously had and want to learn what are the best practices in this regard. So my question is: what's the setup that makes more sense and is more secure between:

Using the crypttab method
Using my current method (LVM on LUKS)
Combining both (using my current LVM volume with crypttab)

Thanks in advance for any reply

frostschutz · 2025-12-17 08:55:24

Swap on LVM on LUKS is good enough, "unusable between reboots" sounds nice but when will it ever matter in practice... so just leave as is, it's good already.

If it's just about getting rid of old data, you could find a way to discard your swap partition on shutdown. In addition to discarding at startup which is already done if you set the right flags. But it would not work if you just pull the plug I guess. Also requires allow-discards and of course discard support by the storage itself, which is usually the case if it's SSD/NVME.

Otherwise with cryptswap on LVM on LUKS, you end up having two layers of LUKS. It works - but it also means there is some additional overhead if your system ever starts swapping for real. Swap is already slow as it is...

LUKS does not have a pass-through mode for already encrypted data to avoid some of that overhead... you could do it with Device Mapper... but that's very non-standard, and outright dangerous if that data segment is ever relocated by either LUKS (reencrypt) or LVM (lvresize, pvmove, ...).

The traditional approach is to have the crypt swap partition completely outside of your LUKS stuff... and then just make sure cryptswap never, ever formats the wrong partition (consider using the UUID or LABEL and offset hack, or make a very specific PARTLABEL at the very least). Downside here is that it's difficult to resize such a partition, you lose the LVM flexibility.

JacoNIX97 · 2025-12-17 09:35:55

Thanks for the reply. Yes I guess it is safe enough, the standard approach is the crypt swap partition though? From a cryptographic standpoint, is there a difference between the two modes? And would there be a noticeable difference in performance as one method is more direct and the other has the overhead from both encryption and LVM?

Lone_Wolf · 2025-12-17 09:42:31

Since you don't need hibernation an alternative could be to use a swapfile (not possible with some filesystems) on an already encrypted partition .
This has the advantage you can change its size easily .

Note that if you have multiple disks (especially if they differ in speed/size) having multiple swapfiles is often beneficial.

frostschutz · 2025-12-17 09:53:43

Lone_Wolf wrote:

Since you don't need hibernation an alternative could be to use a swapfile (not possible with some filesystems) on an already encrypted partition .
This has the advantage you can change its size easily .

LVM already can do the change size etc., so no advantages there.

Swapfiles are a hack for people who don't know how to use LVM properly :-)

mpan · 2025-12-17 10:33:28

A separate swap partition with a random key causes data to effectively be erased each time system is powered down. At no additional cost, passively, even if the storage device enters read-only mode or breaks completely. An additional benefit is that you can place the swap partition just after the “/boot” partition, giving you flexibility to easily grow “/boot” when it becomes small. Shrinking swap is a no-brainer, compared to effort and risk of doing the same to filesystems.

If placed inside an encrypted container, consider swap files instead of separate partitions. You get the same protection, and gain a trivial setup and flexibility. Mind Btrfs has some limits with regard to swap files.

JacoNIX97 · 2025-12-17 10:45:08

How risky would be to delete the LVM volume with the swap partition and resize the LUKS container? And would a program like Gparted be able to manage the shrinking without damaging the remaining LVM volumes?

Lone_Wolf · 2025-12-17 11:37:17

frostschutz wrote:

Swapfiles are ~~a hack~~ for people who don't ~~know how to use LVM properly :-)~~ want to depend on LVM

Fixed that for you

JacoNIX97 · 2025-12-17 12:14:27

JacoNIX97 wrote:

How risky would be to delete the LVM volume with the swap partition and resize the LUKS container? And would a program like Gparted be able to manage the shrinking without damaging the remaining LVM volumes?

Nope, just realized I'd have to move 1TB of LVM volumes to move the free space to the end of the LUKS partition. Not gonna do it .

Thanks everyone for the help!

mpan · 2025-12-17 14:18:57

frostschutz wrote:

Swapfiles are a hack for people who don't know how to use LVM properly :-)

What advantages LVM brings to swap? Why would anybody want swap in an LVM volume, other than if a person happens to be on an LVM setup?

Arch Linux

#1 2025-12-17 08:22:45

Best practice for encrypted swap setup

#2 2025-12-17 08:55:24

Re: Best practice for encrypted swap setup

#3 2025-12-17 09:35:55

Re: Best practice for encrypted swap setup

#4 2025-12-17 09:42:31

Re: Best practice for encrypted swap setup

#5 2025-12-17 09:53:43

Re: Best practice for encrypted swap setup

#6 2025-12-17 10:33:28

Re: Best practice for encrypted swap setup

#7 2025-12-17 10:45:08

Re: Best practice for encrypted swap setup

#8 2025-12-17 11:37:17

Re: Best practice for encrypted swap setup

#9 2025-12-17 12:14:27

Re: Best practice for encrypted swap setup

#10 2025-12-17 14:18:57

Re: Best practice for encrypted swap setup

Board footer