4

I have two LUKS-encrypted SSDs in my laptop: one is the system SSD (nvme0n1), which contains my Home folder encrypted with eCryptfs, and the other is a Data SSD (nvme1n1), which is fully LUKS-encrypted. Both SSDs share the same passphrase. My operating system is LMDE 6.

After a recent update, I was unable to access my system. The error message displayed was: "cryptsetup failed, bad password or options," which I suspect was caused by a failed initramfs update. To resolve the issue, I booted from a live system and, using chroot, I added a new passphrase to the system SSD, which allowed me to regain access to my system.

However, I made a critical mistake. Since the system SSD now had a new passphrase, I proceeded to change the passphrase on the Data SSD via Gnome Disks while the Data SSD was mounted. After rebooting, I was unable to unlock the Data SSD. The error message now says: "Error unlocking /dev/nvme1n1: Failed to activate device: Incorrect passphrase." I'm absolutely certain the passphrase I’m entering is correct.

Unfortunately, I don't have a backup of the Data SSD header. It seems the header is intact, and I suspect the issue might be that the keyslot got damaged during the passphrase change through Gnome Disks.

I’ve attached some outputs from the Data SSD for further analysis. What steps can I take to recover access to the Data SSD?

Output of lsblk:

lsblk

and output of blkid:

blkid

and output of cryptsetup luksDump /dev/nvme1n1:

LUKS header information Version: 2 Epoch: 5 Metadata area: 16384 [bytes] Keyslots area: 16744448 [bytes] UUID: cbdd1cfe-91d3-4771-a8ef-f4db3febacb0 Label: (no label) 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: 8 Memory: 1048576 Threads: 4 Salt: 8e 31 db 5e c1 36 79 f4 13 5d 8e aa 8b cd 75 f5 52 ed ac 81 7b cd 27 e9 f4 da 05 97 4b da 7d 00 AF stripes: 4000 AF hash: sha256 Area offset:290816 [bytes] Area length:258048 [bytes] Digest ID: 0 Tokens: Digests: 0: pbkdf2 Hash: sha256 Iterations: 166970 Salt: 6f aa 5d 52 7d aa 51 65 2b f4 19 89 b6 dc 3c 63 d0 c5 a0 92 a8 5f 8f 92 37 4a f4 b3 a2 f9 2c c7 Digest: d6 1a 7f 0c 5c d3 1e 1e d2 97 b8 65 64 13 46 43 10 d8 f5 94 44 a8 ae b2 eb cb 6a 9f 4a c0 45 df
Improve this question

1 Answer 1

Reset to default
6

The metadata shown by luksDump is correct, otherwise you'd see not a valid LUKS device instead (when the LUKS2 header checksum no longer matches metadata). The epoch and keyslot offset is also consistent with a LUKS2 header that was modified using luksChangeKey once.

So, nothing seems to be wrong. If anything is damaged, it would be the key material of your keyslot.

Unfortunately, there is no way to verify it properly, since LUKS header does not have checksums for key material. It accepts your passphrase, or not.

At most you can superficially check for obvious corruption with hexdump or gzip as suggested in this answer.

# grab the keymaterial according to keyslot offset: # 512 / 8 * 4000 = 256000 bytes dd iflag=skip_bytes,count_bytes skip=290816 count=256000 if=yourluksheader of=keymaterial.dump # should look like random data throughout: hexdump -C keymaterial.dump | less # compression very unlikely to work: $ gzip < keymaterial.dump | wc -c 256058 (not below 256000)

If there's non-random data or gzip manages to noticably compress anything, then it's more likely to be a case of corrupt key material.

I'm absolutely certain the passphrase I’m entering is correct.

Without a working keyslot (or directly providing the master/volume key from somewhere) it is impossible to decrypt any data.

It is unfortunately also not that difficult to make the same typo twice in a row (when asked for the new passphrase twice). So if there is no obvious corruption of key material, you'd have to start brute-forcing possible typos or keyboard layout / input method issues, in hopes of landing on a working variation eventually.

That's assuming Gnome Disks or whatever frontend you were using to change the passphrase, does not have any bugs in this aspect.

LUKS has plenty of keyslots so there is usually no need to change a passphrase unnecessarily; it's safer to add a new one, and only remove the old one some time later when things are verified to work. That or always have a backup passphrase, if not a full header backup.

Improve this answer
10
  • 2
    "... brute-forcing possible typos ..." - Also try it with caps lock on, perhaps it was on when changing the passphrase. You never know. Also, if there's punctuation in the passphrase, like say ', check if the Gnome GUI didn't convert sequences like 'e to é. Extra spaces are also worth trying. Commented Oct 16 at 7:55
  • 2
    Yeah, and charset issues... if this was a data ssd, that is to say the system / gnome environment is still intact, you could try and reproduce the issue on a new LUKS container. If it can be reproduced... you can try to trace what exactly Gnome Disk is doing or passing as the passphrase. But if it was that simple you could probably open it already. Commented Oct 16 at 8:19
  • +100, if I could, for that last para. Never change a key, if you can avoid it; add a new one, verify it, then delete the old one. Commented Oct 16 at 11:13
  • 1
    @kerberos17 I forgot to mention it in the answer, but also run a memtest. Bad ram can completely screw up argon2 results, and I don't know if cryptsetup has any safeguards for that (should verify keymaterial at least once before writing it out). If it does not verify, then trying to change keys on a machine with bad ram could lock you out. Commented Oct 16 at 15:02
  • 1
    @frostschutz I think, you're right with the RAM. I've run the memtest86. It found 76 errors and at the end the test failed, even the OS runs more or less with the garbage RAM. So the question is, is there any hope in that case to recover the key material? Commented Oct 17 at 21:08

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.