LUKS won't accept my passphrase anymore

tjbp · 2026-02-25 11:18:45

Hi all, have been using Arch for a couple of decades but am arguably a newbie when it comes to LUKS, hence posting here. On the latest install on my Thinkpad x270 I chose a LVM on LUKS setup. Regrettably I didn't fully understand the encryption mechanism, and thought as long as I remembered my password I would always be able to decrypt my data. I followed the guide here, so have sadly only discovered cryptsetup's luksDump command now that something has gone wrong (the guide doesn't mention it - I should probably add something to it about it). In short, I don't have a header backup.

After a reboot yesterday, I was asked for my passphrase as normal, but received "No key available with this passphrase." Just prior to this I had run a pacman upgrade, hence the reboot, but unfortunately I didn't see what was upgraded and the pacman.log is obviously encrypted now. Naturally I don't expect any upgrade scripts to have touched my LUKS partition.

I've done a lot of digging, and am posting this thread because I'm actually not yet convinced that my key is corrupt; but first, what I've tried:

Checking my keyboard layout. I've typed my passphrase in directly to verify it's being input properly - the keyboard layout is correct and none of my keys are physically damaged
RAM - I know Argon2id is memory-intensive, so I've done 4 successful passes of memtest on my stick, then actually swapped it to a different stick that is known to work. I've now cloned the drive to a completely different machine to attempt to decrypt. All the same result.
Kernel config: I've tested this on a live USB and am still unable to open the volume, receiving the same error.
I've reviewed the LUKS header with hexdump, and it looks normal in comparison to other headers (no obvious corruption in the form of 00's or FF's).

So at this stage it looks a lot like my key is corrupt. However, my understanding of the LUKS header is it does have some mitigating properties for corruption, such as a SHA-256 digest of the key. According to the below open attempt, the digest matches, so doesn't that mean it's extremely likely my key is not corrupted?

$ cryptsetup --debug open --test-passphrase luks-partition.bin 
# cryptsetup 2.8.4 processing "cryptsetup --debug open --test-passphrase luks-partition.bin"
# Verifying parameters for command open.
# Running command open.
# Installing SIGINT/SIGTERM handler.
# Unblocking interruption on signal.
# Allocating context for crypt device luks-partition.bin.
# Trying to open device luks-partition.bin with direct-io.
# Direct-io read works.
# Initialising device-mapper backend library.
# Trying to load any crypt type from device luks-partition.bin.
# Crypto backend (OpenSSL 3.6.1 27 Jan 2026 [default][legacy][threads][argon2]) initialized in cryptsetup library version 2.8.4.
# Detected kernel Linux 6.18.9-arch1-2 x86_64.
# Loading LUKS2 header (repair disabled).
# Acquiring read lock for device luks-partition.bin.
# Verifying lock handle for luks-partition.bin.
# Device luks-partition.bin READ lock taken.
# Trying to read primary LUKS2 header at offset 0x0.
# Opening locked device luks-partition.bin
# Verifying locked device handle (regular file)
# LUKS2 header version 2 of size 16384 bytes, checksum sha256.
# Checksum:35348f0a194eb2098f2f603902b0627b0f3696ba77211b2111d89e24902eb06a (on-disk)
# Checksum:35348f0a194eb2098f2f603902b0627b0f3696ba77211b2111d89e24902eb06a (in-memory)
# Trying to read secondary LUKS2 header at offset 0x4000.
# Reusing open ro fd on device luks-partition.bin
# LUKS2 header version 2 of size 16384 bytes, checksum sha256.
# Checksum:8f9f9edd40957c25f78bb777db7357acfe837bf2561a7fbf68fb61187b2b83ff (on-disk)
# Checksum:8f9f9edd40957c25f78bb777db7357acfe837bf2561a7fbf68fb61187b2b83ff (in-memory)
# Device size 28212960256, offset 16777216.
# Device luks-partition.bin READ lock released.
# PBKDF argon2id, time_ms 2000 (iterations 0), max_memory_kb 1048576, parallel_threads 4.
# Checking volume passphrase [keyslot -1] using token.
No usable token is available.
# Interactive passphrase entry requested.
Enter passphrase for luks-partition.bin: 
# Checking volume passphrase [keyslot -1] using passphrase.
# Keyslot 0 priority 1 != 2 (required), skipped.
# Trying to open LUKS2 keyslot 0.
# Running keyslot key derivation.
# Reading keyslot area [0x8000].
# Acquiring read lock for device luks-partition.bin.
# Verifying lock handle for luks-partition.bin.
# Device luks-partition.bin READ lock taken.
# Reusing open ro fd on device luks-partition.bin
# Device luks-partition.bin READ lock released.
# Verifying key from keyslot 0, digest 0.
# Digest 0 (pbkdf2) verify failed with -1.
No key available with this passphrase.

From my research, the above suggests the passphrase is simply wrong - if the master key was corrupted a failure would trigger earlier as the digest wouldn't match.

Finally, this is my LUKS header:

LUKS header information
Version:       	2
Epoch:         	3
Metadata area: 	16384 [bytes]
Keyslots area: 	16744448 [bytes]
UUID:          	279b3994-4d49-442d-a44e-803ec43343d4
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:  4
	Memory:     1048576
	Threads:    4
	Salt:       02 41 ce 04 0e f3 70 f2 ed d3 07 d1 43 e2 c0 9d 
	            1e a4 40 3c 2b fb b6 8f 4b d2 00 26 ab b6 34 db 
	AF stripes: 4000
	AF hash:    sha256
	Area offset:32768 [bytes]
	Area length:258048 [bytes]
	Digest ID:  0
Tokens:
Digests:
  0: pbkdf2
	Hash:       sha256
	Iterations: 119809
	Salt:       a8 ba 32 e6 0d c6 34 33 d4 7e b9 f5 60 d9 ab bd 
	            d1 75 9b 20 b8 6f 3d ad 9e 34 27 b9 72 5d 3c fe 
	Digest:     bd 97 9a e4 dc a8 a1 c7 ec c5 46 5b 4c 67 9e 58 
	            eb 13 bb e5 b8 4c b0 6a fa fb bb 7c be ab ba 5f

Last edited by tjbp (2026-02-25 11:19:43)

schard · 2026-02-25 11:35:17

Did you check whether hashing your password with the Argon2id parameters from the LUKS header matches the password has stored there (See: argon2 -h)?
The LUKS header looks fine to me. I'd still bet on a wrong password.
Maybe, when you set up your LUKS encrypted you forgot to set the correct keymap and now the system using a different one.

frostschutz · 2026-02-25 11:57:27

Everything here looks like you're using the wrong passphrase. It could be corrupt key material since the LUKS header has no checksums and no backups for that. (Metadata is checksummed and stored twice in the header, keymaterial has nothing)

There is no way to verify key material (other than providing a working passphrase). LUKS header does not have backups or checksums of key material.

You can extract it, and try to compress it. It should be random data so compression should not work (as in not make it any smaller). If it can be compressed then it's much more likely to be corrupt.

dd if=yourluksdevice bs=1 skip=32768 count=256000 of=keymaterial
hexdump -C keymaterial | less # does it not look entirely random?
xz keymaterial
stat keymaterial.xz # is it smaller than 256000 bytes?

Did anything touch the header recently? cryptsetup itself claims not (Epoch counts go up when using luksChangeKey etc., for any newly created header it's 3). Did you clone, image, move partitions, ...?

Keyboard layout issues are common (if you're not using US layout by default). When using keyfiles, benign issues like surplus newlines are also common. If that's a possibility you can try bruteforcing variations of your passphrase.

With corrupt key material, no amount of bruteforcing will ever produce the correct results.

You could try bit-flipping key material but... despite what some blog posts claim, that's not how data corruption happens usually, unless it was in RAM and rewritten at some point, and RAM happened to be bad...

It's a good idea to have more than one keyslot (can be the same passphrase). This adds a tiny bit of redundancy to the header and would allow it to survive a single bad sector. Unfortunately it won't help you in this situation.

Last edited by frostschutz (2026-02-25 12:00:11)

tjbp · 2026-02-25 11:58:18

schard wrote:

Did you check whether hashing your password with the Argon2id parameters from the LUKS header matches the password has stored there (See: argon2 -h)?
The LUKS header looks fine to me. I'd still bet on a wrong password.
Maybe, when you set up your LUKS encrypted you forgot to set the correct keymap and now the system using a different one.

My understanding is the argon2 hash output is used as the decryption key for the master key - its hash isn't stored in the LUKS header. Or have I misunderstood?

Keymap is a great suggestion, I'm going to look into it now, but I use the UK layout and I think the default is US, which sadly doesn't swap the position of any of the keys used in my password.

tjbp · 2026-02-25 12:13:07

frostschutz wrote:

Everything here looks like you're using the wrong passphrase. It could be corrupt key material since the LUKS header has no checksums and no backups for that. (Metadata is checksummed and stored twice in the header, keymaterial has nothing)
There is no way to verify key material (other than providing a working passphrase). LUKS header does not have backups or checksums of key material.
You can extract it, and try to compress it. It should be random data so compression should not work (as in not make it any smaller). If it can be compressed then it's much more likely to be corrupt.
dd if=yourluksdevice bs=1 skip=32768 count=256000 of=keymaterial
hexdump -C keymaterial | less # does it not look entirely random?
xz keymaterial
stat keymaterial.xz # is it smaller than 256000 bytes?
Did anything touch the header recently? cryptsetup itself claims not (Epoch counts go up when using luksChangeKey etc., for any newly created header it's 3). Did you clone, image, move partitions, ...?
Keyboard layout issues are common (if you're not using US layout by default). When using keyfiles, benign issues like surplus newlines are also common. If that's a possibility you can try bruteforcing variations of your passphrase.
With corrupt key material, no amount of bruteforcing will ever produce the correct results.
You could try bit-flipping key material but... despite what some blog posts claim, that's not how data corruption happens usually, unless it was in RAM and rewritten at some point, and RAM happened to be bad...
It's a good idea to have more than one keyslot (can be the same passphrase). This adds a tiny bit of redundancy to the header and would allow it to survive a single bad sector. Unfortunately it won't help you in this situation.

Thanks, attempted the compression, compressed size was 256080 bytes. Haven't touched any partitions since initial setup of the drive. Not using a keyfile either, systemd would ask me for the password on boot and I'd type it in each time. My keyboard layout is UK - unfortunately while my keymap was probably US when I would type my passphrase, it was only alpha characters and there's no difference between US & UK for those.

frostschutz · 2026-02-25 12:30:37

Well, there is no obvious corruption then. Inconclusive.

Was the header stored on a raid like device? If there's a mirror device, or parity mismatch, maybe that could help recover a different version of the header.

It could be a misbehaving drive but that's not very typical. You could try reading the header from the original drive many times in a row (uncached) and check if you get the same data every time. Sectors are checksummed so it's supposed to report read errors instead of returning garbage data...

Otherwise, not much you can do about the header. It's either corrupted, or not. No way to tell.

That leaves grasping at straws. Maybe your brain is playing tricks on you or you persistently typo'd it in the same way until yesterday. Maybe there's a script that corrupts headers (that'd be terrible, but then I guess you wouldn't be alone here).

Not sure what to recommend. Chances of survival dwindling into single-digits and all that...

Last edited by frostschutz (2026-02-25 12:31:34)

tjbp · 2026-02-25 16:25:51

No RAID I'm afraid. Tried reading the key material from the disk 100k times using dd iflag=direct and it hashed to the same digest every time.

Weirdly I think that leaves something to do with keyboard input or me forgetting the password I've been entering every week for the last couple of years.

seth · 2026-02-25 16:38:18

I didn't see what was upgraded and the pacman.log is obviously encrypted now.

Do you remember your last update before this one?
And when the last working boot happened?
Did you do anything explicitly wrt the encryption or partition/volume layout before the fatal reboot?

And do you have a spare keyboard?
You could end up receiving bogus non-printable input, spoiling your password (though that's quite a stretch)
Since you might even get that from other devices, check evtest or libinput debug-events for spurious input.

frostschutz wrote:

persistently typo'd it in the same way until yesterday

What is the supposed passphrase?
Capital mistakes? BE ./. AE spelling?

tjbp · 2026-02-25 16:58:52

Last update was probably a couple of weeks ago, but can't be 100%, sorry. Last working boot was probably around the same time frame, maybe up to a month ago. Haven't touched the encryption, partition/volume or anything to do with it for a long time, probably a couple of years at least.

I do have a spare keyboard - have tried plugging that in and attempting, though am already attempting to unlock a dump of the partition on my desktop anyway. Have attempted typing in the passphrase via original keyboard, USB keyboard, over SSH, on a separate machine into the partition dump.

The passphrase comprises entirely of lowercase letters of the latin alphabet, ie. /^[a-z]+$/, no numbers or symbols.

Only keyboard scenario I can picture now is that I've had an unusual keymap for all this time in my initramfs, that was also used to configure the passphrase originally, which has been removed in a recent update, but that does seem quite far-fetched (should add that I don't ever intentionally use a keymap besides the UK one).

Last edited by tjbp (2026-02-25 17:00:21)

seth · 2026-02-25 22:04:42

Any chance you crossed the busybox to systemd switch for mkinitcpio.conf w/ the update?
(Though since you also cannot open the container offline that's unlikely the cause)

The two prominent layouts next to qwerty are qwertz (which is only relevant if your password includes the swapped Y/Z) and azerty (you'll have to manually transcribe the password, the layout is crazy
But you would have to have crated the container w/ the bogus layout in use AND then set/add that for the initramfs. Far-fetched is putting that mildly.

Do other people have access to the system?
Was the luks container locked when you were sleeping/hibernating it (did you at all)?
Have you tried some permutations (especially if you're actually just using it very infrequently on boots you might actually be wrong about the passwords details - if you didn't write it down somehwere)

kostjanix · 2026-02-27 12:17:08

do you have overclocked your ram(expo/xmp)? especially on amd and especially when using more than one stick per dram-channel? from my testing I found out, that you can easily fall into a spot where a system boots normally, memtest is okay with the current configuration, yet argon2 is so sensitive against ram-stability, that luks-unlocks can fail and made it look like a wrong password's fault. i wrote an article about that and wrote a little testscript to find out, if you're affected by this: https://blog.tastatursport.de/2023/06/a … s-devices/

Last edited by kostjanix (2026-02-27 12:17:48)

frostschutz · 2026-02-27 13:24:50

Yeah, I didn't mention it, because OP was already aware of the issue, memtested and even used another PC. It would be great if it was ram, because that's something you can fix, as long as the header hasn't been corrupted yet because of it (which is a risk with luksChangeKey in particular, but this header does not look like it was ever changed after creation).

It's also possible for argon2 to be set to use too much ram, rendering you unable to open it on a low-end machine. However cryptsetup does print warnings in that case, so you would probably notice...

tjbp · 2026-03-02 12:20:26

seth wrote:

Any chance you crossed the busybox to systemd switch for mkinitcpio.conf w/ the update?
(Though since you also cannot open the container offline that's unlikely the cause)
The two prominent layouts next to qwerty are qwertz (which is only relevant if your password includes the swapped Y/Z) and azerty (you'll have to manually transcribe the password, the layout is crazy
But you would have to have crated the container w/ the bogus layout in use AND then set/add that for the initramfs. Far-fetched is putting that mildly.
Do other people have access to the system?
Was the luks container locked when you were sleeping/hibernating it (did you at all)?
Have you tried some permutations (especially if you're actually just using it very infrequently on boots you might actually be wrong about the passwords details - if you didn't write it down somehwere)

Thanks, tried with the other layouts of qwertz and azerty and no success sadly. No other people with access, and I don't believe the LUKS container was locked when sleeping or hibernating - just rebooted as normal after finishing the upgrade (which included a new kernel). Am going to try some passphrase permutations next on the off-chance there was a stray space at the beginning or something.

kostjanix wrote:

do you have overclocked your ram(expo/xmp)? especially on amd and especially when using more than one stick per dram-channel? from my testing I found out, that you can easily fall into a spot where a system boots normally, memtest is okay with the current configuration, yet argon2 is so sensitive against ram-stability, that luks-unlocks can fail and made it look like a wrong password's fault. i wrote an article about that and wrote a little testscript to find out, if you're affected by this: https://blog.tastatursport.de/2023/06/a … s-devices/

I've now tried unlocking on a different machine altogether and still have the problem (as frostschutz has mentioned), but thanks.

Last edited by tjbp (2026-03-02 12:20:41)

Arch Linux

#1 2026-02-25 11:18:45

LUKS won't accept my passphrase anymore

#2 2026-02-25 11:35:17

Re: LUKS won't accept my passphrase anymore

#3 2026-02-25 11:57:27

Re: LUKS won't accept my passphrase anymore

#4 2026-02-25 11:58:18

Re: LUKS won't accept my passphrase anymore

#5 2026-02-25 12:13:07

Re: LUKS won't accept my passphrase anymore

#6 2026-02-25 12:30:37

Re: LUKS won't accept my passphrase anymore

#7 2026-02-25 16:25:51

Re: LUKS won't accept my passphrase anymore

#8 2026-02-25 16:38:18

Re: LUKS won't accept my passphrase anymore

#9 2026-02-25 16:58:52

Re: LUKS won't accept my passphrase anymore

#10 2026-02-25 22:04:42

Re: LUKS won't accept my passphrase anymore

#11 2026-02-27 12:17:08

Re: LUKS won't accept my passphrase anymore

#12 2026-02-27 13:24:50

Re: LUKS won't accept my passphrase anymore

#13 2026-03-02 12:20:26

Re: LUKS won't accept my passphrase anymore

Board footer