Talk:Dm-crypt/Swap encryption

Enter Passphrase

Anyone know what to do about the "Please enter passphrase for disk myswap (swap)!" and "systemd-ask-password" msgs diplaying at bootup? Occurs with the Without suspend-to-disk mode. Voukait (talk) 07:32, 8 May 2016 (UTC)

Which hooks do you use in mkinitcpio for the encryption? Any kernel parameter for "resume=" that might trigger it? --Indigo (talk) 09:32, 8 May 2016 (UTC)

Ive been investigating this further and it appears that it is this issue. https://bbs.archlinux.org/viewtopic.php?id=176927 Which looks like the problem is caused by formating the partition as swap, and then the runtime encryption fails because it detects it as a swap drive. As soon as I can change the partition type, I will confirm.

Voukait (talk) 23:38, 10 May 2016 (UTC)

Adding my 2cents here: I was having the same problem due to a mistake I made when following the steps. It seems that I had used the wrong cipher (i.e. I mixed two different techniques: with kernel naming and with label, because I did it all in order before encountering the warning about the potential changes of names and decided to adapt to it.) To correct it, I had to replace : safeSwap LABEL=cryptswap /dev/urandom swap,offset=2048,cipher=aes-cbc-essiv:sha256,size=512 #WRONG CIPHER METHOD with: safeSwap LABEL=cryptswap /dev/urandom swap,offset=2048,cipher=aes-xts-plain64,size=512 #WORKS LIKE A CHARM I therefore suggest emphasizing the fact that the chosen cipher type is important to save other people's time. I was maybe not the only one to fall for it, if I can refer to this thread: https://bbs.archlinux.org/viewtopic.php?id=193566 Bruno- (talk) 19:35, 5 September 2020 (UTC)

Alternative approach for ZFS with swap on a Luks partition

I am using the approach listed on this website,

https://aaronlauterer.com/blog/2017/04/arch-linux-on-an-encrypted-zfs-root-system/

With this approach the Luks cryptroot partition is partitioned further into a SWAP and ZFS root partition. The advantage of this approach is that a single password is needed for both ZFS and SWAP parition.

—This unsigned comment is by Trumee (talk) 08:23, 3 April 2021‎. Please sign your posts with ~~~~!

tune2fs -O read-only

In the section Without suspend-to-disk support > UUID and LABEL, wouldn’t it be a good idea to mark the ext2 filesystem as read-only with tune2fs -O read-only?

Kugland (talk) 08:23, 1 January 2022 (UTC)

suspend-to-disk mkinitcpio hook: suggest something like /dev/disk/by-uuid/<uuid> over /dev/<device>

In section Suspend-to-disk support --> Using a swap partition --> mkinitcpio hook, in `/etc/initcpio/hooks/openswap`, I think it'd be better to suggest `/dev/disk/by-uuid/<uuid>` over `/dev/<device>`, if going by the recommendation to not use block device names in config files. Keiichiiownsu12 (talk) 19:37, 20 November 2023 (UTC)

Sounds reasonable. You can use a pseudo-variable for the UUID value: XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX. Also, /dev/disk/by-uuid/ can be replaced with UUID=. -- nl6720 (talk) 08:57, 21 November 2023 (UTC)

Encrypted swap GPT automounting

It's possible to GPT automount an encrypted swap partition, you just need to use any of the default methods that systemd-cryptsetup tries before falling back to password entry. Encrypt the swap partition, then run systemd-cryptenroll --tpm2-device (for example, makes more sense with PCR policies but I only tested with basic tpm2. Should work the same though). Then run mkswap on /dev/mapper/swap, then reboot and swapon shows /dev/dm-1 partition (size) -used) -2. Cvlc (talk) 19:25, 19 August 2024 (UTC)

Encrypted swapfile on Btrfs

I'm not a fan of dedicated partitions, and like the flexibility Btrfs subvolumes or ZFS datasets offer.

My setup uses a single Btrfs partition on NVMe SSD, and a swapfile in a subvolume.

There isn't a ton of information out there about encrypting a swapfile without encrypting the whole drive or by using LUKS.

I experimented with crypttab to see if it would accept files as devices.

On a basic test system without hibernation, I edited /etc/crypttab to include the swapfile path /swap/swapfile instead of specifying a dedicated /dev. /swap resides on subvol system/@swap and is mounted on boot as any regular subvol using /etc/fstab.

/etc/crypttab

# Configuration for encrypted block devices.
# See crypttab(5) for details.

# NOTE: Do not list your root (/) partition here, it must be set up
#       beforehand by the initramfs (/etc/mkinitcpio.conf).

# <name>       <device>                                     <password>              <options>
# home         UUID=XXXXXXXX                                /etc/mypassword1
# data1        /dev/sda3                                    /etc/mypassword2
# data2        /dev/sda5                                    /etc/cryptfs.key
# swap         /dev/sdx4                                    /dev/urandom            swap,cipher=aes-cbc-essiv:sha256,size=256
# vol          /dev/sdb7                                    none

swap           /swap/swapfile                               /dev/urandom            swap,cipher=aes-cbc-essiv:sha256,size=256

In /etc/fstab, /swap/swapfile is replaced by /dev/mapper/swap as swap.

/etc/fstab

/dev/nvme0n1p2
UUID=XXXXXXXXX       /swap           btrfs           rw,relatime,ssd,discard=async,space_cache,subvolid=282,subvol=/system/@swap   0 0

/dev/mapper/swap     none            swap            defaults        0 0

swapon -s shows /dev/dm-0 (or any other dm-X) as the swap device, and lsblk shows loop0 as crypt [SWAP]

I haven't tested this on a production system.

--Nitrogen (talk) 12:08, 14 October 2025 (UTC)

AES-128 or AES-256 for plain dm-crypt

cryptsetup 2.6.0 release notes said that in the next cryptsetup version "The default encryption mode will be AES-XTS with 512bit key (AES-256)", so I updated the page accordingly ahead of the time to use cipher=aes-xts-plain64,size=512.

cryptsetup 2.7.0 was released, but its release notes say that "The default key size remains 256 bits (it means using AES-128 as XTS requires two keys)". cryptsetup --help confirms this:

$ cryptsetup --help | grep plain:

        plain: aes-xts-plain64, Key: 256 bits, Password hashing: sha256

dm-crypt/Encrypting an entire system#Plain dm-crypt and dm-crypt/Device encryption#Encryption options for plain mode use --key-size 512 which matches with what LUKS uses by default, so IMO it's fine to deviate from the defaults of plain mode there.

What do we do with "non-persistent" encrypted devices such as swap and tmp in dm-crypt/System configuration#crypttab and to_be_wiped in dm-crypt/Drive preparation#dm-crypt wipe on an empty device or partition? Should they keep the key size as 256 (i.e. AES-128) or switch to 512 (i.e. AES-256)?

--nl6720 (talk) 11:11, 5 August 2024 (UTC)

If no one objects, I'll change all except for the "to_be_wiped" devices to use a 512-bit keys (i.e. AES-256) so that it matches with what LUKS uses by default. -- nl6720 (talk) 09:55, 5 September 2024 (UTC)

I am of the opinion that we should go for AES-128, because:

• It's faster, because it has fewer rounds.
• It's enough, per https://eprint.iacr.org/2019/1492.pdf. (AES-128 could have issues with multi-target attack, but XTS mitigates it.)

The only issue is that it's not "quantum-safe", because theoretically it takes 2^64 operations on a quantum computer, which is less than the 2^100 "safe amount", to break quantumly. But uh... how many operations per second do those things do again? --Arthur2e5 08:45, 13 September 2024 (UTC)

AES-128 being faster is the reason I suggest still using it when wiping devices.

While we typically try not to deviate from cryptsetup defaults, IMO it is worth it this time since LUKS defaults are usually better than plain mode's. And there are precedents as aes-xts-plain64 was used in wiki pages long before it replaced aes-cbc-essiv:sha256 as the default plain mode cipher.

-- nl6720 (talk) 06:30, 14 September 2024 (UTC)

I support going for XTS too: it's faster, and it's wide block, which increases the granularity of changes. However, our issue here is the size=512 part: I still strongly believe it is unnecessary with about (14/10 - 1) = 40% more rounds of computation. When we do swap, we want speed too. Arthur2e5 08:30, 14 September 2024 (UTC)

¯\_(ツ)_/¯ Let's keep everything as-is then. --nl6720 (talk) 09:15, 5 October 2024 (UTC)

Here we go again

User:Lahwaacz: here we go again. Oh snap, I did misread this when I revisited. Well well, my 256 edit was wrong. Let's keep this here for a bit more, lest I forget a third time. I should look into some brain-training exercise.

Re: the too much crypto note marked for rm, I think it has merit but needs rewriting. On my overloaded system (mprime p-1 work) the throughput difference is much higher than 40%. Given a PCIe 5.0 NVMe swap this can be totally relevant.

As for where to put it: sure it can be in device encryption. Might as well add xchacha12,aes-adantium-plain64 there to cover our bases. Still, the "hypothetical quantum security"-for-speed trade is probably more relevant here than in the general case for your average disk-encrypter. --Arthur2e5 12:12, 2 November 2025 (UTC)