Can't luksOpen swap partition using keyfile

General system Newbie
1

Hello,
I’m restructuring the data portion on this system’s ssd and created a new swap partition.
All three partitions (data, swap, root) are LUKS encrypted.
I’m passing on the data & swap passphrases via keyfiles pointed at in /etc/crypttab for smooth booting.
The data partition opens fine, but for swap I’ve to enter the passphrase during the boot process.
I can handle the swap partition just fine in the command line, but not by opening using the keyfile:

$ sudo cryptsetup -v luksOpen /dev/nvme0n1p4 cryptswap --key-file=/etc/crypttab.keyfiles
No usable token is available.
No key available with this passphrase.
Command failed with code -2 (no permission or bad passphrase).

Opening by entering the passphrase on the command line works as expected.
The configuration looks exactly the same as the data partition.
I suspected a typo, non-ascii character etc, deleted the keyfile, typed in a new one, same error.
I edited /etc/crypttab to use the same working keyfile for both partitions, changed the passphrase for the swap partition accordingly, same problem.
Manual opening always works.
I did a luksDump of both partitions and did a side-by side comparison, no obvious deviations from a nominal output.
I triple-checked the UUIDs in /etc/crypttab.
I zeroed out the swap partition, again did a luksFormat etc. - same error message.
And I while I was at it anyway I tried all this while being booted from an ISO - so the ssd wasn’t ‘live’.
Any idea what I’m missing here?
Thanks a lot, Michael.

2

Sorry if this is obvious, but please just clarify:

You did actually additionaly add the key file as a password to a password slot (e. g. slot 2) next to the passphrase that seems to unlock the swap device?

I’ve read your post twice but don’t quite understand the problem. You do know a key file in this context is a actual file and not a “textfile” containing your passphrase?

3

Can you show output of:

cryptsetup luksDump /dev/nvme0n1p4

Just to see how many key slots are taken.

You can test passphrases with:

cryptsetup --verbose open --test-passphrase /dev/nvme0n1p4 --key-file=/etc/crypttab.keyfiles

4

yes, thanks. That’s one of the things I did.

Output of luksDump for p4:

LUKS header information
Version:       	2
Epoch:         	3
Metadata area: 	16384 [bytes]
Keyslots area: 	16744448 [bytes]
UUID:          	30fa8dc8-4d04-4c42-938b-b868d6308ceb
Label:         	swap
Subsystem:     	(no subsystem)
Flags:       	(no flags)

Data segments:
  0: crypt
	offset: 16777216 [bytes]
	length: (whole device)
	cipher: aes-xts-plain64
	sector: 512 [bytes]

Keyslots:
  0: luks2
	Key:        512 bits
	Priority:   normal
	Cipher:     aes-xts-plain64
	Cipher key: 512 bits
	PBKDF:      argon2id
	Time cost:  4
	Memory:     1048576
	Threads:    4
	Salt:       21 e3 f7 09 a3 73 80 9b a9 f7 fc 65 49 17 1a 03 
	            55 69 2d c7 fb 2f d2 0d e7 06 28 0b 86 a4 06 0a 
	AF stripes: 4000
	AF hash:    sha256
	Area offset:32768 [bytes]
	Area length:258048 [bytes]
	Digest ID:  0
Tokens:
Digests:
  0: pbkdf2
	Hash:       sha256
	Iterations: 116612
	Salt:       d1 b9 0b 60 13 d0 18 91 65 7b 68 9e 2c ae e0 66 
	            c5 f3 9e fd c5 16 2e 99 1b 10 9f a6 78 ac 8c 91 
	Digest:     90 99 43 4d 9d 9a fd 5d 1c 9d 1e 60 e6 55 1a 99 
	            09 d2 15 dc a6 60 3f 74 4f aa 8d b3 dd 67 03 1f

So it’s one slot.
And that’s the only difference to p2 (data) which has two key slots.

5

Yes, and this one slot is the password. The key file should be on the second slot.

Just do:

cryptsetup luksAddKey /dev/nvme0n1p4 --key-file=/etc/crypttab.keyfiles

This will put the keyfile in the next open slot = #2

6

Yesss! I did not spot this as not nominal! Thanks a lot!
EDIT:
PS: the command was

cryptsetup luksAddKey /dev/nvme0n1p4 /etc/crypttab.keyfiles
7

This works for quite some time. Otherwise I couldn’t mount the data partition.
See cryptsetup manpage:
A passphrase stored in a file is called a key file. The only difference between a passphrase and a key file is that a key file can contain binary data. Both are processed the same.