Can't open luks after switching distros

My computer broke and I am now regressed to a 32 bit p4. The problem is that my passphrase is said to be incorrect

% uname -a
Linux P4 4.9.0-4-686-pae #1 SMP Debian 4.9.65-3+deb9u1 (2017-12-23) i686 GNU/Linux

I am running Devuan (Debian derivative), Linux and I tried the native cryptsetup 1.7.3-4 and I also compiled and tried with 1.7.5 which is compiled by default against libgcrypt20 1.7.6-2+deb9u2 .

I tried several different ways to write my passphrase without success. I did type it out and then copy it via screen as soon as I noticed that I was having trouble so that there was no chance of typing errors. I last opened the container and partition using knoppix on this system. Container is a backup of of the files on a home filesystem which is also encrypted with the same passphrase. I have tried to luks open both the container and the filesystem without success.
I have no recollection as to which gcrypt/crypsetup my 64-bit or knoppix live dvd use(s|d).

Thanks,
David

I would try:

1. Shut down. Disconnect your backup and home drives. Install a new drive.

2. Boot OS. Set up partition, LUKS container, and file system on new drive.

3. Shut down. Connect your backup and home drives.

4. Boot Knoppix live CD. Open all LUKS containers. Mount backup and home file systems read-only. Mount new drive file system read-write. Copy backups and home data to new drive.

5. Shutdown. Disconnect backup and home drives.

6. Boot new OS and verify new drive has backups and home data.

David

This is not important, all distros and combinations should work (for 1.7 stable) the same if kernel has all needed crypto available.
(With some exceptions like broken Whirlpool in gcrypt but we have workaround for that.)

Could you please post cryptsetup command that fails (luksOpen) with debug log (add --debug option) and luksDump?

Without it is hard to say what is really failing. If it is just passphrase and your LUKS keyslot is corrupted, then there is unfortunately no way to recover it without header backup.

Milan

On 9 Jun 2018 16:35 -0400, from [email protected] (David Niklas):

The first thing I'd do is to make absolutely certain that the passphrase you're entering is being given to cryptsetup in the same way as it was before. For example, you'd want to verify that the keyboard layout and locale encoding (UTF-8 vs US-ASCII vs ISO-8859-1 vs whatever) are exactly the same as on the system where you most recently were able to open the container. If you don't know what those settings were, this may take a bit of fiddling around. Running "locale" and "locale -a" would be a good start, as would verifying the keyboard layout; if Devuan is like Debian in this regard, start at /etc/default/keyboard and /etc/default/console-setup.

For the future, once you've (hopefully) sorted things out, consider adding a second keyslot with a long passphrase that is strictly US-ASCII, strictly for recovery purposes, and saving a LUKS header backup somewhere other than within the container (obviously). You could even use a greatly increased iteration count for that one. That way, if all else fails, you can restore the header backup, type the passphrase into a text editor (so you can see what you're typing) and paste the passphrase into the prompt.

Consider making a LUKS header backup now, before doing any further testing, if you don't have sufficient spare disk to make a copy of the entire encrypted container (which would be even better). That way, if you mess up further, at least you'll be able to get back to where you are now.

Michael Kjörling • https://michael.kjorling.se • [email protected]
  “The most dangerous thought that you can have as a creative person
              is to think you know what you’re doing.” (Bret Victor)