"No key available with this passphrase" with LUKS suddenly on boot

Support and Help
,
1

Ubuntu Version:

22.04

Desktop Environment (if applicable):

Problem Description:

Suddenly no longer able to boot into my machine. “No key available with this passphrase” with LUKS suddenly on boot. The issue occured June 5th/6th and after this, I haven’t been able to get into my machine.

My system has a full disk encryption and I have been using it for 6 months, daily without any issues. On June 5th/6th I was working on the machine and I had to install some packages for a project I was working on. I ran sudo apt update && sudo apt --fix-broken install, all good thus far, I continued working into the night, when I realised the machine was still turned on at 2 AM, I decided to do a force shutoff (pressing the button).

I am 100% confident the password for the encrypted partition is correct, and although the LUKS header appears to be ok, I am unable to get it unlocked after the days mentioned above.

As of now I am out of ideas of what could have happened, or even how to solve it as I am unable to narrow down the cause or even problem.

Thanks for taking the time to read this post.

Relevant System Information:

Luks header dump

LUKS header information
Version:       	2
Epoch:         	3
Metadata area: 	16384 [bytes]
Keyslots area: 	16744448 [bytes]
UUID:          	8722d52f-b4a2-41be-8cb8-a1523a905d36
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:     984225
	Threads:    4
	Salt:       8a 21 33 5b c2 ee 5b b5 01 42 06 45 8b f8 9f eb 
	            8c d2 2d 7c 7d 52 45 f2 87 d1 02 76 c7 10 74 99 
	AF stripes: 4000
	AF hash:    sha256
	Area offset:32768 [bytes]
	Area length:258048 [bytes]
	Digest ID:  0
Tokens:
Digests:
  0: pbkdf2
	Hash:       sha256
	Iterations: 121138
	Salt:       c5 20 50 be 2f 57 d4 8a 5b 2c 86 c7 06 0c 79 a4 
	            7a e8 81 81 12 77 cb 50 24 7e a9 c7 2e 5b c1 30 
	Digest:     49 d8 5a 67 4f c0 aa 4c 48 55 2f 25 c4 41 bc 49 
	            52 91 fe 6e f3 36 47 df 7d d2 8f 34 3b 3c 6b e1

Luks keyslot checker output

Tool: https://gitlab.com/cryptsetup/cryptsetup/-/tree/master/misc/keyslot_checker
Text:

root@2c6489dac96a:~/keyslot_check# ./chk_luks_keyslots -v ~/luksheader.img 

parameters (commandline and LUKS header):
  sector size: 512
  threshold:   0.900000

- processing keyslot 0:  start: 0x008000   end: 0x047000 
- processing keyslot 1:  keyslot not in use
- processing keyslot 2:  keyslot not in use
- processing keyslot 3:  keyslot not in use
- processing keyslot 4:  keyslot not in use
- processing keyslot 5:  keyslot not in use
- processing keyslot 6:  keyslot not in use
- processing keyslot 7:  keyslot not in use
- processing keyslot 8:  keyslot not in use
- processing keyslot 9:  keyslot not in use
- processing keyslot 10:  keyslot not in use
- processing keyslot 11:  keyslot not in use
- processing keyslot 12:  keyslot not in use
- processing keyslot 13:  keyslot not in use
- processing keyslot 14:  keyslot not in use
- processing keyslot 15:  keyslot not in use
- processing keyslot 16:  keyslot not in use
- processing keyslot 17:  keyslot not in use
- processing keyslot 18:  keyslot not in use
- processing keyslot 19:  keyslot not in use
- processing keyslot 20:  keyslot not in use
- processing keyslot 21:  keyslot not in use
- processing keyslot 22:  keyslot not in use
- processing keyslot 23:  keyslot not in use
- processing keyslot 24:  keyslot not in use
- processing keyslot 25:  keyslot not in use
- processing keyslot 26:  keyslot not in use
- processing keyslot 27:  keyslot not in use
- processing keyslot 28:  keyslot not in use
- processing keyslot 29:  keyslot not in use
- processing keyslot 30:  keyslot not in use
- processing keyslot 31:  keyslot not in use
root@2c6489dac96a:~/keyslot_check#

Screenshots or Error Messages:

What I’ve Tried:

  1. I initially believed it to be a RAM related issue, but I ran memtester for 9 passes / 24 hours, with no RAM issues detected.
  2. Checked Luks keyslots with https://gitlab.com/cryptsetup/cryptsetup/-/tree/master/misc/keyslot_checker, results appear OK, check relevant information section for ouput.
  3. Tried to bruteforce the luks header on a different machine with different keyboard layouts (eg, dvorak), in case I had gotten used to making some typos - no luck.
  4. Tried alternative keyboard layouts, current layout & was set during installation on boot is FI (finnish) - no luck.
  5. Attempted to access and unlock the drive from a live USB instance also - no luck.
2

“ No key available with this passphrase ” simply means the bytes you type no
longer match the only keyslot that exists in the header. The dump you posted
shows a healthy LUKS2 header with one keyslot (slot 0), so nothing is
“half-deleted” or repairable the slot just will not decrypt with the string
you are entering.

Things to verify before you declare the data lost:

Keyboard layout
Boot any live-USB, switch to the US layout, and run

sudo cryptsetup open --type luks2 /dev/sdX test --test-passphrase

(replace /dev/sdX with the real device).
If it still says No key available…, the problem is not a layout mismatch.

Hidden typo when the passphrase was set/changed
If at some point you changed the passphrase while your layout was
Dvorak/Finnish/etc., the actual bytes stored could differ from what you
remember. Try the same keystrokes on US layout; try variants with
Shifted characters, stray spaces, or a numeric keypad turned on.

Old backup header
Did you ever run

cryptsetup luksHeaderBackup /dev/sdX --header-backup-file header.img

or keep Timeshift / rsnapshot copies of the first 2 MiB of the disk?
Restoring a header made before the passphrase went bad will instantly
revive access.

If every layout permutation fails and you have no header backup and no
second keyslot, there is no cryptographic way around the problem the master
key is sealed by Argon2id with 512-bit AES and a 1 MiB memory cost; brute-
forcing it is effectively impossible. At that point the only recovery path
is restoring the filesystem from whatever external backup you have.

Force-power-off itself cannot change a LUKS passphrase; most likely the key
was changed accidentally (or mistyped twice when you added it) sometime
before the reboot, and you are now seeing the result.

1 Like
3

Hi, thank you for the response. Unfortunately no back ups were stored (wow, what a valueable lesson learned)!.

You mentioned that the LUKS header looks healthy, but could it still be that the header is simply corrupt and that is the reasoning the password is no longer matching?

If the header is corrupt, would it be recoverable / what could be done to test this theory further?

I also want to rule out password amnesia, so I will probably attempt some hypnotherapy to rule it out, although I am confident that my password is correct, but whatever the reason is, I am just unable to get into the system.

Many thanks.

4

The header itself looks healthycryptsetup can parse it and its checksums
match so the trouble is that the key derived from what you type no longer
matches keyslot 0.

Things still worth trying

# A quick sanity-check
sudo cryptsetup open --test-passphrase /dev/sdX

If this always returns
No key available with this passphrase
the slot is readable but the passphrase bytes are wrong.

Replay the keystrokes under every layout/case mix you can think of

# US layout
sudo loadkeys us
cryptsetup open --test-passphrase /dev/sdX

# Finnish layout
sudo loadkeys fi
cryptsetup open --test-passphrase /dev/sdX

# Try again with Caps-Lock on, Num-Lock on, etc.

That single typo or layout swap at the moment you set the key is by far
the most common cause of “suddenly wrong password”.

Hunt for an old header backup

find / -type f -name '*luks*header*' 2>/dev/null

Any luksHeaderBackup.img or plain dd if=/dev/sdX of=header.img bs=2M count=1
you made during install would let you restore the original keyslot:

sudo cryptsetup luksHeaderRestore /dev/sdX --header-backup-file header.img

Rule out silent keyslot corruption

If the slot were truly corrupted you’d see “Keyslot 0: invalid” or similar.
Your dump shows the AF stripes pass integrity, so corruption is almost
certainly not the issue.

Reality check

No header backup + no matching passphrase = the drive stays locked.
Argon2id + AES-XTS 512-bit is not brute-forcible.

Going forward

# After you recover or reinstall
# 1. Add a second keyslot
cryptsetup luksAddKey /dev/sdX

# 2. Save an external header backup
cryptsetup luksHeaderBackup /dev/sdX \
    --header-backup-file /media/usb/luks_header_$(date +%F).img

Two keyslots and an off-disk header copy will save you from this in the
future. Good luck with the keyboard-layout permutations fingers crossed the
correct byte sequence is still in your muscle memory!

5

I can vouch for this one as worth trying. Once I accidentally set the original key with the caps lock on by mistake. Then after reboot, I couldn’t get in. I finally figured it out. But, the opposite can also happen. For numbers, I don’t use the keypad, just the numbers at the top. These are all simple tries, but certainly worth a shot.

You may want to consider setting more than one key in the future. You can even export a key to a USB that can save you in the future if this happens again.