Can't unlock encrypted disk

z0gnadal · 01-19-2020, 03:56 AM

I use Debian default encryption disk encryption. Only /boot it's not encrypted. When I boot I need to type my password, and then I will be logged in. But now I can't login. It always says that I typed the wrong password, but I typed the correct password.

I tried to boot in live-CD and try unlock volume from there. But It always says wrong password.
Before that I had an achieve that had a 90GB file in it and I tried to underachieve it, but it gave me error not enough space. I get notification that I'm out of space 600mb left, but when type df -h I saw I have same amount of space as before I start to unarchieving file. Looks like file was autodeleted by Debian system.
I have no BADs on disk. Sometimes I have some issues with RAM module and I my PC stucks but I always can unlock the disk. In that case I need to clean RAM module and PC is not stucking anymore. I tried remove RAM modules and boot with only one of them, but still can't unlock disk. I have 2 HDDs with Debian and only one of them is not unlocking. Other one is working fine.
https://i.postimg.cc/gYjmdvw5/1.jpg

When I try to boot like this
https://i.postimg.cc/k4ZDcchY/2.jpg
I get this
https://i.postimg.cc/CxVmhys7/3.jpg
When I boot like this
https://i.postimg.cc/YSCN0tG6/4.jpg
I get
https://i.postimg.cc/wT5Dk1D5/5.jpg
https://i.postimg.cc/d0fC0rKF/6.jpg

pan64 · 01-20-2020, 12:39 AM

I would say this is a problem with the disk, you need to find the first error. In picture 3 there is an nvidia related error too.
Or probably something else, but we have no information to say more.

berndbausch · 01-20-2020, 01:41 AM

Quote:

Originally Posted by z0gnadal

It always says wrong password.

If the password is correct and the LUKS header is corrupted, you can recreate the header from a header backup. See point 4.2 of the cryptsetup FAQ. The answer also suggests a way to guess whether the keyslot is corrupted.

If the header is OK but the password is not correct, this is a case for cryptsetup luksAddKey. A LUKS header has room for 8 pass phrases, as the luksDump command shows. Too late in your case, but perhaps next time?
You could also try a password cracker, but that would take time and powerful computers.

Also, if the encrypted data is useful, back it up (i.e. not only a LUKS header backup).

I am afraid these would be the only options to get your data back.

z0gnadal · 01-20-2020, 11:03 AM

Quote:

Originally Posted by pan64

I would say this is a problem with the disk, you need to find the first error. In picture 3 there is an nvidia related error too.
Or probably something else, but we have no information to say more.

I checked disk and there was no Bad sectors. Nvidia related error was always from start. Just say what information and I will provide it.

Quote:

Originally Posted by berndbausch

If the password is correct and the LUKS header is corrupted, you can recreate the header from a header backup. See point 4.2 of the cryptsetup FAQ. The answer also suggests a way to guess whether the keyslot is corrupted.

If the header is OK but the password is not correct, this is a case for cryptsetup luksAddKey. A LUKS header has room for 8 pass phrases, as the luksDump command shows. Too late in your case, but perhaps next time?
You could also try a password cracker, but that would take time and powerful computers.

Also, if the encrypted data is useful, back it up (i.e. not only a LUKS header backup).

I am afraid these would be the only options to get your data back.

I think screenshots show header is not corrupted, but I'm not sure I'm not expert in Linux.
Yes too late now, now I can't cryptsetup luksAddKey. I didn't even think that header/encryption... can get corrupted without reason. I was using PC just like always.
If I can't recover data and it's lost forever. Is there a way I find the reason why this happen ?

berndbausch · 01-20-2020, 01:06 PM

Quote:

Originally Posted by z0gnadal

I didn't even think that header/encryption... can get corrupted without reason. I was using PC just like always.

A cosmic ray turning a single bit is enough. The header doesn't have a checksum; just by looking at the output you can't judge if it's corrupted.

Quote:

If I can't recover data and it's lost forever. Is there a way I find the reason why this happen ?

I doubt it. Best guess is checking the system log.

rknichols · 01-20-2020, 02:05 PM

For people using something other than the default "US English" keyboard mapping, LUKS keyslot problems are often traced to mapping issues. Is there any chance that this is the problem?

The only tool that attempts to check for corrupted keyslot data is the chk_luks_keyslots program that is referenced in FAQ section 4.2. That tool evaluates the "randomness" of the keyslot data, and any block with a low randomness score is an indication that the block may have been overwritten. That tool must be compiled from the misc/ directory in the cryptsetup source. There is no other test for corruption of the keyslot data.

The LUKS header is deliberately designed so that any corruption makes the key unrecoverable. The only protection against that is having a backup of the LUKS header.

z0gnadal · 01-20-2020, 10:34 PM

Quote:

Originally Posted by berndbausch

A cosmic ray turning a single bit is enough. The header doesn't have a checksum; just by looking at the output you can't judge if it's corrupted.

I doubt it. Best guess is checking the system log.

Seems I can't because I can't login. Is there any other way to check system logs ?

Quote:

Originally Posted by rknichols

For people using something other than the default "US English" keyboard mapping, LUKS keyslot problems are often traced to mapping issues. Is there any chance that this is the problem?

The only tool that attempts to check for corrupted keyslot data is the chk_luks_keyslots program that is referenced in FAQ section 4.2. That tool evaluates the "randomness" of the keyslot data, and any block with a low randomness score is an indication that the block may have been overwritten. That tool must be compiled from the misc/ directory in the cryptsetup source. There is no other test for corruption of the keyslot data.

The LUKS header is deliberately designed so that any corruption makes the key unrecoverable. The only protection against that is having a backup of the LUKS header.

I'm not sure, but I boot in initramfs and checked. Text look like English text. I'm using English but not sure US or other one.
Can I chk_luks_keyslots from live cd ? I just need to repeat all actions from README and just replace /dev/loop0 with /dev/sda6 in my case?

berndbausch · 01-20-2020, 11:19 PM

Quote:

Originally Posted by z0gnadal

Seems I can't because I can't login. Is there any other way to check system logs ?

If they are encrypted, no. I realize that my suggestion was not very useful.

Quote:

I'm not sure, but I boot in initramfs and checked. Text look like English text. I'm using English but not sure US or other one.
Can I chk_luks_keyslots from live cd ? I just need to repeat all actions from README and just replace /dev/loop0 with /dev/sda6 in my case?

Personally I have never done that, but I don't see a reason why it shouldn't work from a live CD.

rknichols · 01-21-2020, 08:32 AM

Quote:

Originally Posted by z0gnadal

Can I chk_luks_keyslots from live cd ?

Quote:

Originally Posted by berndbausch

Personally I have never done that, but I don't see a reason why it shouldn't work from a live CD.

I don't know of any live CD that includes that program. A compiled chk_luks_keyslots isn't typically distributed as part of the cryptsetup package. You have to download the source on a Linux system with development tools installed and compile it yourself. I have no idea why that tool is buried that way.

z0gnadal · 01-21-2020, 10:41 AM

Thank you
I duplicate this:
I just need to repeat all actions from README and just replace /dev/loop0 with /dev/sda6 in my case?
Sorry for flood, but just want to be sure that I don't destroy/damage anything on that disk or other disk

rknichols · 01-21-2020, 12:19 PM

Quote:

Originally Posted by z0gnadal

I just need to repeat all actions from README and just replace /dev/loop0 with /dev/sda6 in my case?
Sorry for flood, but just want to be sure that I don't destroy/damage anything on that disk or other disk

Yes. The chk_luks_keyslots program does not write anything to the device it is checking. It's only output is messages to the terminal.

slac-in-the-box · 01-22-2020, 09:46 AM

Quote:

Originally Posted by rknichols

The only protection against that is having a backup of the LUKS header.

Thanks. This has prompted me to back up the LUKS headers on the multiple encrypted drives around our home... I knew that, and have even lost a TB of family media to this exact problem in the past, and still sometimes forget on a fresh install to backup the headers. I am going to suggest to the maintainer of my favorite distro that he includes this step in his README_CRYPT, the file with LUKS instructions for slackware.

Code:

cryptsetup luksHeaderBackup /dev/sda# --header-backup-file ~/luksheaderbak
scp ~/luksheaderbak rem.ote.ip:~/

(pointless to have a header backup in the encrypted volume, so I copied it to another device.)

Question: Is the key contained in the header? If an attacker had this header's backup, would they be able to retrieve a key from it, with this chk_luks_keyslots program? If so, that explains why you have to custom compile it in. I never tape my passwords under my desk drawer--they're all in my head--but a file that could unlock everything, I must now protect too.

rknichols · 01-22-2020, 12:24 PM

Quote:

Originally Posted by slac-in-the-box

Question: Is the key contained in the header? If an attacker had this header's backup, would they be able to retrieve a key from it, with this chk_luks_keyslots program? If so, that explains why you have to custom compile it in. I never tape my passwords under my desk drawer--they're all in my head--but a file that could unlock everything, I must now protect too.

That backup header is just a binary copy of the first ~2MB (larger for LUKS2) of the LUKS container. The header contains copies of the master key encrypted by each of the up to 8 allowed passphrases/keyfiles. Having a copy of that header would allow an adversary to perform an offline guessing attack attempting to discover a passphrase.

z0gnadal · 01-22-2020, 12:43 PM

I want to compile keyslot_checker , but I get error

Code:

gcc -lm -lcryptsetup chk_luks_keyslots.c -o chk_luks_keyslots 
chk_luks_keyslots.c:39:27: fatal error: libcryptsetup.h: No such file or directory
 #include <libcryptsetup.h>

in FAQ they say

Code:

 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.  Note
that this tool requires a libcryptsetup from cryptsetup 1.6.0 or
later (which means libcryptsetup.so.4.5.0 or later).  If the tool
complains about missing functions in libcryptsetup, you likely have
an earlier version from your distribution still installed.  You can
either point the symbolic link(s) from libcryptsetup.so.4 to the new
version manually, or you can uninstall the distribution version of
cryptsetup and re-install that from cryptsetup >= 1.6.0 again to fix
this.

but I use version newer than 1.6.0

Code:

 apt-cache policy cryptsetup
cryptsetup:
  Installed: 2:1.7.3-4
  Candidate: 2:1.7.3-4
  Version table:
 *** 2:1.7.3-4 100
        100 /var/lib/dpkg/status

How can I fix this ? I don't understand how to point the symbolic link(s) from libcryptsetup.so.4 to the new version manually.

berndbausch · 01-22-2020, 04:06 PM

The FAQ you cite has nothing to do with your problem. The FAQ is about running the program, but you don't even have a program yet that can be run. You need to compile it first.

Your problem is likely that you have to download the entire source code including the missing header file, not just chk_luks_keyslots.c. Or that header file is not at a location where the compiler finds it.