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)Reply
Voukait (talk) 23:38, 10 May 2016 (UTC)Reply
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)Reply
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 ~~~~!
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 ?
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)Reply
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 . Cvlc (talk) 19:25, 19 August 2024 (UTC)Reply
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.
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 .
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)". confirms this:
dm-crypt/Encrypting an entire system#Plain dm-crypt and dm-crypt/Device encryption#Encryption options for plain mode use 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 in dm-crypt/Drive preparation#dm-crypt wipe on an empty device or partition? Should they keep the key size as (i.e. AES-128) or switch to (i.e. AES-256)?
--nl6720 (talk) 11:11, 5 August 2024 (UTC)Reply
I am of the opinion that we should go for AES-128, because:
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)Reply
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. --Arthur2e5 12:12, 2 November 2025 (UTC)Reply