You are not logged in.

#1 2019-12-07 00:10:10

mik3911
Member
Registered: 2019-12-07
Posts: 7

Suddenly unable to access encrypted LUKS partition anymore

NOTICE: Given the situation and lack of alternative solutions, if anyone wants to help me and dig more into the problem I'm available to share my LUKS header, passphrase or whatever information you might need for a further analysis upon request by form email. Thanks in advance.

Hello.

Few hours ago, after rebooting my system, I tried typing my passphrase to decrypt my LVM on LUKS partition as usual but got "No key available with this passphrase". Needless to say I made several attempts, carefully checked that I didn't activate the cap lock and I'm 100% sure the password is correct since I have been doing this every day for some time. The last thing I made before shutting down my system was updating some packages, (among the others, linux kernel to 5.4.2) but I didn't notice anything weird respect to other times and I'm inclined to say this is not the source of the problem after looking more carefully into this.

No matter what I tried, I always get the same output every time:
- Booting from a Live USB and trying to access the encrypted partition from there.
- Giving the password from a file or a command pipeline (in order to exclude keyboard issues).
- Booting form the kernel fallback image and a backup of an old EFI image.

I use Arch regularly and didn't have such a problem before. The most obvious explanation of this is a possible LUKS header corruption but I checked this with a cryptsetup tool (https://gitlab.com/cryptsetup/cryptsetu … ot_checker) and it looks like the header doesn't present any evident anomaly. By the way, my partition is LUKS2 encrypted, I read in some posts that LUKS2 has a backup header but I didn't find anything more.

I'm literally desperate because I actually spent a lot of time trying to configure my system and I had some important stuff in there but I know I have to put the blame on me for not doing a backup of the LUKS header.
Any help is really much appreciated, if you need additional information let me know.

P.S. BTW sorry for my bad English (I'm not a native English speaker) and inexperience (I'm a newbie).

EDIT: This is the output of cryptsetup luksDump:

LUKS header information
Version:       	2
Epoch:         	3
Metadata area: 	12288 bytes
UUID:          	b6551310-03a0-4360-b0c9-0dc4b128b4c1
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
	PBKDF:      argon2i
	Time cost:  5
	Memory:     1048576
	Threads:    4
	Salt:       6d 71 12 59 d2 b2 69 33 08 78 2f 51 6e 22 db 7c 
	            a4 49 68 c8 a3 43 31 97 86 4b 8e f7 dd 42 2c bd 
	AF stripes: 4000
	Area offset:32768 [bytes]
	Area length:258048 [bytes]
	Digest ID:  0
Tokens:
Digests:
  0: pbkdf2
	Hash:       sha256
	Iterations: 144830
	Salt:       a6 e7 19 31 53 cc 44 19 12 fc 1c 4c 49 5d 15 16 
	            ce 03 b3 46 85 86 b7 ef 94 ef 98 43 5b 9c e7 06 
	Digest:     74 30 fd 3c aa 67 ec 7b 37 ff 83 e2 ad 7f cd 9f 
	            76 26 8c 96 a0 c8 22 1b 5d b7 99 11 fc 29 0b 5e

I also did cryptsetup isLuks and the command was successful.

Just to give you more information about the system, I use a dual-boot setup on a Lenovo T480 with Windows 10 and Arch Linux on the same SSD drive. I have secure boot enabled with my own keys and a normally encrypted LVM on LUKS for Arch. One thing I noticed in the previous days was that my EFI partition was almost full, don't know if that might be relevant.

Last edited by mik3911 (2019-12-09 08:57:21)

Offline

#2 2019-12-07 11:29:06

sabroad
Member
Registered: 2015-05-24
Posts: 242

Re: Suddenly unable to access encrypted LUKS partition anymore

Sometimes, SSDs return uncorrectable errors for reads. It'd be worth checking dmesg after trying an unlock.

(Purposefully) difficult to test if a key is corrupted but try 4. Troubleshooting:

4.2 I cannot unlock my LUKS container! What could be the problem? wrote:

In order to find out whether a key-slot is damaged one has to look for "non-random looking" data in it.  There is a tool that automatizes this in the cryptsetup distribution from version 1.6.0 onwards.  It is located in misc/keyslot_checker/.  Instructions how to use and how to interpret results are in the README file.


--
saint_abroad

Offline

#3 2019-12-07 11:43:01

mik3911
Member
Registered: 2019-12-07
Posts: 7

Re: Suddenly unable to access encrypted LUKS partition anymore

Hi, thanks for the reply.

The tool you suggested is the one I was talking about in the original post for checking the keyslots, this is its output:

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

It looks ok since the entropy is not too low. Honestly, the header doesn't seem to be damaged, even by looking at the output of hexdump (https://docdro.id/ZzaGixS), but I've no idea what else could have happened. It's possible that updating the kernel broke something but I don't know how I can re-install it since I can't access the root partition.

Last edited by mik3911 (2019-12-07 11:44:18)

Offline

#4 2019-12-07 14:07:05

sabroad
Member
Registered: 2015-05-24
Posts: 242

Re: Suddenly unable to access encrypted LUKS partition anymore

mik3911 wrote:

- Giving the password from a file or a command pipeline (in order to exclude keyboard issues).

Hypotheis: it was the wrong keyboard layout when working, and now doesn't work with the right layout.

Worth a try with US English keyboard layout.


--
saint_abroad

Offline

#5 2019-12-07 15:20:09

mik3911
Member
Registered: 2019-12-07
Posts: 7

Re: Suddenly unable to access encrypted LUKS partition anymore

I've always used the US English keyboard layout (never changed the layout) and even when typing the password from a live USB I made sure the text was indeed correct by typing on a text editor.

Since the header doesn't seem to be evidently damaged, the keyboard might be the problem somehow. I would like to backup the LUKS header and try opening it on another device. As stated in the cryptsetup FAQ, a command like this should be used with a detached header:

 cryptsetup --header <file> open --type luks2 <device> </dev/mapper/ -name> 

but a device parameter is still needed. However, the man page of the cryptsetup command states:

WARNING: There is no check whether the ciphertext device specified actually belongs to the header given. In fact, you can specify an arbitrary device as the ciphertext device for open with the --header option. Use with care.

I don't understand, are there any consequences if I try to open the LUKS header on another device with the above command by specifying a different/not-existing device (e.g. device could actually be damaged) ? My answer would be no but I just want a confirmation in order to avoid to mess up another system.

Apart from this, I have no idea what else I could try to do to solve the problem. Thanks for your help by the way.

Last edited by mik3911 (2019-12-07 15:21:13)

Offline

#6 2019-12-07 17:14:56

frostschutz
Member
Registered: 2013-11-15
Posts: 1,417

Re: Suddenly unable to access encrypted LUKS partition anymore

don't use --header file

your data offset seems to be 16MiB so just make a file with luks header plus some data in it (e.g. by dumping 32 Megs):

dd bs=1M count=32 if=/dev/luks of=/mnt/somewhere/luks.img

then you can just try to open that anywhere

cryptsetup luksOpen luks.img luksname

Offline

#7 2019-12-07 21:10:14

mik3911
Member
Registered: 2019-12-07
Posts: 7

Re: Suddenly unable to access encrypted LUKS partition anymore

frostschutz wrote:

don't use --header file

your data offset seems to be 16MiB so just make a file with luks header plus some data in it (e.g. by dumping 32 Megs):

dd bs=1M count=32 if=/dev/luks of=/mnt/somewhere/luks.img

then you can just try to open that anywhere

cryptsetup luksOpen luks.img luksname

Hi, thanks for the suggestion.

I've just tried decrypting the header with your method on another system and unfortunately the result was the same.
As last desperate move, I'll try to use the cryptsetup mailing list and hope someone can figure this out but at this point I think it's better to give up and move on.
Thanks anyway for your help.

Last edited by mik3911 (2019-12-07 21:10:44)

Offline

#8 2019-12-07 22:52:01

frostschutz
Member
Registered: 2013-11-15
Posts: 1,417

Re: Suddenly unable to access encrypted LUKS partition anymore

For more you'd probably have to share your header, passphrase and some data to test decryption key against. But yeah, it seems pretty hopeless. If the passphrase stops working and you ruled out both kernel bug and cryptsetup bug (by using older version that worked), as well as user error (wrong keyboard, wrong pass, ...) then it's usually gone for good.

And sharing your passphrase would at most help rule out the user error part... there's some pitfalls to look out for, like not all characters on my (german) keyboard are part of ASCII so e.g. if you ended up using § in the passphrase, encoding issues might be a possibility as well... but it's not like anyone can magick themselves around the encryption.

Last edited by frostschutz (2019-12-07 23:06:40)

Offline

#9 2019-12-08 10:52:40

mxfm
Member
Registered: 2015-10-23
Posts: 163

Re: Suddenly unable to access encrypted LUKS partition anymore

- Giving the password from a file or a command pipeline (in order to exclude keyboard issues).

Was your password hashed in LUKS? I cannot say for LUKS, but in plain dm-crypt (I use) my password was hashed, so providing keyfile with plain password is wrong. Did you provide keyfile or redirected stdin in terminal?

Does LUKS data serves as boot partition? Is it bootable device or just partition with user data?

Did you check opening luks header on different system on the same machine or was it a different one?

P.S.

It is definetely not normal that you cannot decrypt LUKS data when 1) LUKS header is OK 2) no keyboard issue 3) no RAM/disk issue - cryptsetup should not fail in these circumstances. I advice to contact cryptsetup mailing list.

Offline

#10 2019-12-08 12:02:36

mik3911
Member
Registered: 2019-12-07
Posts: 7

Re: Suddenly unable to access encrypted LUKS partition anymore

frostschutz wrote:

For more you'd probably have to share your header, passphrase and some data to test decryption key against.

Yeah I was actually thinking to do so, If anyone wants to dig more into the problem I'm available to share my LUKS header, passphrase or whatever information you might need upon request by form email.

But yeah, it seems pretty hopeless. If the passphrase stops working and you ruled out both kernel bug and cryptsetup bug (by using older version that worked), as well as user error (wrong keyboard, wrong pass, ...) then it's usually gone for good.

I might have done something wrong but I tried everything I could in order to understand what actually happened, if anyone has any other ideas or suggestions feel free to share them.

And sharing your passphrase would at most help rule out the user error part... there's some pitfalls to look out for, like not all characters on my (german) keyboard are part of ASCII so e.g. if you ended up using § in the passphrase, encoding issues might be a possibility as well... but it's not like anyone can magick themselves around the encryption.

Well, I can actually say that my password contains only letters and numbers, so I would exclude encoding issues of any sort.

Offline

#11 2019-12-08 12:25:06

mik3911
Member
Registered: 2019-12-07
Posts: 7

Re: Suddenly unable to access encrypted LUKS partition anymore

mxfm wrote:

Was your password hashed in LUKS? I cannot say for LUKS, but in plain dm-crypt (I use) my password was hashed, so providing keyfile with plain password is wrong. Did you provide keyfile or redirected stdin in terminal?

As far as I can tell from the cryptsetup manual, the password provided through the --key-file option of the cryptsetup command is the plain passphrase and is processed (hashed) only afterwards unless you specify other parameter options. I checked this before trying and I've also seen other examples online doing the same, I might have been mistaken though. However, I tried decrypting the header on a different system both on the same machine (Arch live usb and Ubuntu live usb) and another machine (Ubuntu live usb) and the result was exactly the same so this should exclude the keyboard issue (correct me if I'm wrong).

Does LUKS data serves as boot partition? Is it bootable device or just partition with user data?

No, the boot partition is not encrypted, only the classic root-home-swap trio is part of the LUKS data as described here (https://wiki.archlinux.org/index.php/Dm … VM_on_LUKS).

Did you check opening luks header on different system on the same machine or was it a different one?

Tried both, same result.

It is definetely not normal that you cannot decrypt LUKS data when 1) LUKS header is OK 2) no keyboard issue 3) no RAM/disk issue - cryptsetup should not fail in these circumstances. I advice to contact cryptsetup mailing list.

Yeah it's definitely not normal, that's why I still have few hopes to recover it but everything seems to point to a not-visible damage of the LUKS header. I've already contacted the cryptsetup mailing list, let's see how it goes.

Offline

#12 2019-12-08 15:41:40

frostschutz
Member
Registered: 2013-11-15
Posts: 1,417

Re: Suddenly unable to access encrypted LUKS partition anymore

mik3911 wrote:

If anyone wants to dig more into the problem I'm available to share my LUKS header, passphrase or whatever information you might need upon request by form email.

Feel free to send me a copy, probably there will be no result either, but at least then you know it's not just you...

Offline

#13 2019-12-08 19:13:51

mxfm
Member
Registered: 2015-10-23
Posts: 163

Re: Suddenly unable to access encrypted LUKS partition anymore

frostschutz wrote:
mik3911 wrote:

If anyone wants to dig more into the problem I'm available to share my LUKS header, passphrase or whatever information you might need upon request by form email.

Feel free to send me a copy, probably there will be no result either, but at least then you know it's not just you...

Me too.

Offline

#14 2019-12-08 22:32:14

mik3911
Member
Registered: 2019-12-07
Posts: 7

Re: Suddenly unable to access encrypted LUKS partition anymore

Sent both of you the data, thanks again.

Offline

Board footer

Powered by FluxBB