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)

Dm-crypt/Swap + systemd-networkd = system not booting

See also Talk:Systemd-networkd#systemd-networkd + Dm-crypt/Swap = system not booting

I encountered issue on fresh install on small VPS (1Gb RAM, 1vCPU) that if I have systemd-networkd and crypt-swap then boot process hangs while waiting for crypt-swap device. Posted workaround here: https://bbs.archlinux.org/viewtopic.php?pid=1882917#p1882917

Gregosky (talk) 06:29, 16 January 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)

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)

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)