0

For some reason, I can't add a key to my encrypted swap.

My /etc/crypttab:

swap_crypt /dev/disk/by-partuuid/c4f049d5-ae21-44d6-b753-6e72b7e21770 none luks,swap,discard,keyscript=decrypt_keyctl
root_crypt UUID=26f3c181-e041-47f2-929b-de631a2f1d3f none luks,discard,keyscript=decrypt_keyctl

So to identify those disks:

# ls -l /dev/disk/by-partuuid/c4f049d5-ae21-44d6-b753-6e72b7e21770
lrwxrwxrwx 1 root root 15 Mar  5 22:34 /dev/disk/by-partuuid/c4f049d5-ae21-44d6-b753-6e72b7e21770 -> ../../nvme0n1p7
# blkid |grep 26f3c181-e041-47f2-929b-de631a2f1d3f
/dev/nvme0n1p8: UUID="26f3c181-e041-47f2-929b-de631a2f1d3f" TYPE="crypto_LUKS" PARTUUID="b178ae44-cf49-4dce-b7b5-293c9c0bb9c7"

So I know my swap is on /dev/nvme0n1p7 and my root is /dev/nvme0n1p8.

Now, when I try to add a key for root:

# cryptsetup luksAddKey /dev/nvme0n1p8
Enter any existing passphrase:

Everything works fine, however, for swap:

# cryptsetup luksAddKey /dev/nvme0n1p7

It just exits. A little more info:

# cryptsetup luksAddKey -v --debug /dev/nvme0n1p7
# cryptsetup 2.0.2 processing "cryptsetup luksAddKey -v --debug /dev/nvme0n1p7"
# Running command luksAddKey.
# Locking memory.
# Installing SIGINT/SIGTERM handler.
# Unblocking interruption on signal.
# Allocating context for crypt device /dev/nvme0n1p7.
# Trying to open and read device /dev/nvme0n1p7 with direct-io.
# Initialising device-mapper backend library.
# Trying to load any crypt type from device /dev/nvme0n1p7.
# Crypto backend (gcrypt 1.8.1) initialized in cryptsetup library version 2.0.2.
# Detected kernel Linux 5.0.0-050000-generic x86_64.
# Loading LUKS2 header.
# Opening lock resource file /run/cryptsetup/L_259:7
# Acquiring read lock for device /dev/nvme0n1p7.
# Verifying read lock handle for device /dev/nvme0n1p7.
# Device /dev/nvme0n1p7 READ lock taken.
# Trying to read primary LUKS2 header at offset 0.
# Opening locked device /dev/nvme0n1p7
# Veryfing locked device handle (bdev)
# Trying to read secondary LUKS2 header at offset 8192.
# Opening locked device /dev/nvme0n1p7
# Veryfing locked device handle (bdev)
# Trying to read secondary LUKS2 header at offset 16384.
# Opening locked device /dev/nvme0n1p7
# Veryfing locked device handle (bdev)
# Trying to read secondary LUKS2 header at offset 32768.
# Opening locked device /dev/nvme0n1p7
# Veryfing locked device handle (bdev)
# Trying to read secondary LUKS2 header at offset 65536.
# Opening locked device /dev/nvme0n1p7
# Veryfing locked device handle (bdev)
# Trying to read secondary LUKS2 header at offset 131072.
# Opening locked device /dev/nvme0n1p7
# Veryfing locked device handle (bdev)
# Trying to read secondary LUKS2 header at offset 262144.
# Opening locked device /dev/nvme0n1p7
# Veryfing locked device handle (bdev)
# Trying to read secondary LUKS2 header at offset 524288.
# Opening locked device /dev/nvme0n1p7
# Veryfing locked device handle (bdev)
# Trying to read secondary LUKS2 header at offset 1048576.
# Opening locked device /dev/nvme0n1p7
# Veryfing locked device handle (bdev)
# Trying to read secondary LUKS2 header at offset 2097152.
# Opening locked device /dev/nvme0n1p7
# Veryfing locked device handle (bdev)
# Trying to read secondary LUKS2 header at offset 4194304.
# Opening locked device /dev/nvme0n1p7
# Veryfing locked device handle (bdev)
# LUKS2 header read failed (-22).
# Device /dev/nvme0n1p7 READ lock released.
# Releasing crypt device /dev/nvme0n1p7 context.
# Releasing device-mapper backend.
# Unlocking memory.
Command failed with code -1 (wrong or missing parameters).

Any idea what the problem is?

1

If an encrypted swap is not also intended as hibernation resume device, it is often initialized using a randomly-generated key that is not stored persistently anywhere. That provides a pretty strong guarantee that any forensic attempts to analyze the contents of the swap area will be useless once the system is properly shut down.

As the only copy of such a non-persistent key key in RAM will be actively zeroed as part of a normal shutdown once the crypto device is closed, any attempts to recover the key from RAM contents after a complete shutdown will also be useless.

The fact that your crypttab includes the option swap suggests that this scheme might be in use: the swap option causes cryptsetup to run mkswap on /dev/mapper/swap_crypt after initializing the encryption, which would only be needed if the existing contents of the swap partition was unreadable gibberish... i.e. encrypted with a different non-persistent key.

When using systemd init system, the keyscript= option might be ignored, and systemd's cryptsetup helper be used instead, depending on choices made by your Linux distribution. See man systemd-cryptsetup-generator and man systemd-cryptsetup@.service for details.

  • Hrm, this is possible, but two things: 1) It is used as a resume device for hibernation, and 2) When keyscript is not used, I am asked for 2 passwords. Also, when booting, if I use the new password (swap mount is first) it is labeled as invalid and I have to re-enter the old password. So the swap does have the password stored and it is used at boot. – Fmstrat Mar 6 at 14:48
0

So I figured this out on my own eventually. For anyone who runs into this, make sure that when running cryptsetup status /dev/mapper/<device> that the type is LUKS1 and not PLAIN. It appears the Ubuntu installer defaulted improperly, so standard LUKS commands did not work on the device. Since it was swap I was able to recreate the encryption properly, and now all works smoothly.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.