Arch Linux

seniorgeek

Member

Registered: 2022-04-08

Posts: 4

[SOLVED] SORT OF ...cryptsetup error

Tried installing Arch using archinstall and kept getting python errors during the cryptsetup phase.  (I have used archinstall several times in the past with no problems)

Tried cryptsetup manually and it refuses to open the encrypted partition or even acknowledge its existence.

Various things I have tried:
- Several options with cryptsetup:
  -- with and without "--type luks2"
  -- with and without "-s 0"
- various passphrases
- Deleting and recreating the partition "/dev/nvme0n1p2" using fdisk

Here is my most recent attempt:

1 root@archiso ~ # cryptsetup -y -v luksFormat --type luks2 -s 0 /dev/nvme0n1p2
WARNING: Device /dev/nvme0n1p2 already contains a 'crypto_LUKS' superblock signature.

WARNING!
========
This will overwrite data on /dev/nvme0n1p2 irrevocably.

Are you sure? (Type 'yes' in capital letters): YES
Enter passphrase for /dev/nvme0n1p2: 
Verify passphrase: 
Existing 'crypto_LUKS' superblock signature on device /dev/nvme0n1p2 will be wiped.
Existing 'crypto_LUKS' superblock signature on device /dev/nvme0n1p2 will be wiped.
Key slot 0 created.
Command successful.
cryptsetup -y -v luksFormat --type luks2 -s 0 /dev/nvme0n1p2  25.55s user 0.40s system 97% cpu 26.740 total
root@archiso ~ # cryptsetup open /dev/nvme0n1p2 root                         
Enter passphrase for /dev/nvme0n1p2: 
No key available with this passphrase.
Enter passphrase for /dev/nvme0n1p2: Error reading passphrase from terminal.
cryptsetup open /dev/nvme0n1p2 root  7.41s user 0.07s system 75% cpu 9.847 total
1 root@archiso ~ # cryptsetup status /dev/nvme0n1p2
Device nvme0n1p2 not found

I am using the following:
- archlinux-2022.09.03-x86_64.iso
- cryptsetup 2.5.0 flags: UDEV BLKID KEYRING KERNEL_CAPI

Any thoughts?

Last edited by seniorgeek (2022-09-17 21:00:41)

frostschutz

Member

Registered: 2013-11-15

Posts: 1,472

Re: [SOLVED] SORT OF ...cryptsetup error

cryptsetup status is for active crypt mappings under /dev/mapper/, /dev/nvme0n1p2 is a regular block device so it's normal for cryptsetup status not to work here

# cryptsetup status /dev/md0
Device md0 not found
# cryptsetup status luksmd0
/dev/mapper/luksmd0 is active and is in use.
  type:    LUKS2
  cipher:  aes-xts-plain64
  keysize: 512 bits
...

you probably meant to check with luksDump

# cryptsetup luksDump /dev/md0
LUKS header information
Version:       	2
Epoch:         	6
Metadata area: 	16384 [bytes]
Keyslots area: 	2064384 [bytes]
UUID:          	891324e0-dd0d-465c-a666-004142a8012d
...

the UUID should change after a successful luksFormat

not sure what you mean by -s 0

for testing the passphrase, you can just use a single letter, or empty (just hit enter) if the passphrase is not accepted afterwards, I would assume that something is corrupting your luks header (key material) somehow

you can also test cryptsetup on a regular file

truncate -s 100M foobar.img
cryptsetup luksFormat foobar.img
cryptsetup open foobar.img foobar

Last edited by frostschutz (2022-09-17 13:48:06)

seniorgeek

Member

Registered: 2022-04-08

Posts: 4

Re: [SOLVED] SORT OF ...cryptsetup error

[SOLVED] SORT OF ...
Everything works as it should if LUKS1 (-- type luks1) is specified.  However, the open command fails if LUKS2 (-- type luks2) is specified when initially encrypting the partition.

Interestingly, if the partition is initially encrypted using LUKS1 and then converted to LUKS2, open works.

I am guessing there is some sort of bug in cryptsetup luksFormat.  According to the date on the file in /usr/bin, it was updated on 28 July

frostschutz

Member

Registered: 2013-11-15

Posts: 1,472

Re: [SOLVED] SORT OF ...cryptsetup error

Can you reproduce it on a regular file (foobar.img)? If yes then a bug in cryptsetup would be more likely. If no then some user error, or some corruption on your storage device, is more likely. It's very unusual in any case.

LUKS1 vs LUKS2 stores their key material in different location, with different data offsets, so device corruption (or some other process writing where it shouldn't) could hit it in a different way.

Instead of luksFormating the partition directly, you could create an external header, copy it to the disk, that would give you two identical headers; then if the on-disk header stops working, you can do a byte-by-byte comparison to see whether it got corrupted. (cmp -l external_header.img /dev/partition)

seniorgeek

Member

Registered: 2022-04-08

Posts: 4

Re: [SOLVED] SORT OF ...cryptsetup error

Thanks for the replies.

Just to eliminate the possibility of of a defective Arch iso, I downloaded "archlinux-x86_64.iso" from a different mirror and  loaded it on a different usb-drive after verifying the hash. (Previously, I had tried "archlinux-2022.07.01-x86_64.iso" {I had an old version loaded on a usb-drive} and "archlinux-2022.09.03-x86_64.iso" on another usb-drive.)

I was successful in encrypting and opening foobar.img using the code you suggested on another computer running 5.19.9-arch1-1.

However, the new computer refuses to open an encrypted partition created with the default type or a specified type of luks2.  It works without a problem when specifying luks1.

Since I don't really need the luks2 features, I am going to proceed specifying luks1.

BTW, I did wipe the file systems using:

 wipefs -a 

and wiped the data using

 dd if=/dev/zero of=/dev/nvme0n1p1 status=progress 

between encryption attempts.

You mentioned the possibility of corruption on the storage device.  Could you expound on that theory?  I would think that luks2 would be more robust / error correcting than luks1 since luks2 writes the header info to the front and back of the drive and luks1 only writes it to the front.

frostschutz

Member

Registered: 2013-11-15

Posts: 1,472

Re: [SOLVED] SORT OF ...cryptsetup error

luks2 has checksum for its metadata, but only for its metadata - not the key material

for both luks1 and luks2, if you corrupt the key material, all you get is "No key available with this passphrase."

no other errors, just the passphrase is no longer accepted as it no longer matches the corrupted key material

### deliberately corrupting luks2 key material ###

# truncate -s 100M foobar.img
# cryptsetup luksFormat foobar.img
Enter passphrase for foobar.img: foobar
Verify passphrase: foobar
# cryptsetup luksOpen foobar.img foobar
Enter passphrase for foobar.img: foobar
# cryptsetup close foobar

### works fine, now corrupt it

# cryptsetup luksDump foobar.img
[...]
Keyslots:
  0: luks2
	Key:        512 bits
	Priority:   normal
        [...]
	Area offset:32768 [bytes]
	Area length:258048 [bytes]
	Digest ID:  0

### so key material is at offset 32768, corrupt it:

# dd conv=notrunc bs=1 count=4 seek=32768 if=/dev/urandom of=foobar.img
4+0 records in
4+0 records out

### result

# cryptsetup luksOpen foobar.img foobar
Enter passphrase for foobar.img: foobar
No key available with this passphrase.

Key material corruption is one reason why you'd get the "No key available" error. LUKS is corrupted and irrecoverable at this point (unless you have another keyslot that still works, or an intact backup of the LUKS header).

A more common reason for the "correct" passphrase to be rejected is using a wrong keyboard layout, i.e. you're typing correctly but since the keyboard layout is different, what cryptsetup receives is the incorrect phrase and so it's rejected.

I sometimes add the same passphrase in both us and de layouts so LUKS will accept either one.

----

Hence the theory that something might be corrupting your key material.

If you have that issue on that PC in general  (for both persistent storage, and the file based experiment) then it's a bug or you're doing something wrong (or some other issue like bad ram). But if it only happens for the LUKS header on the SSD partition, something might be going on with your storage.

Last edited by frostschutz (2022-09-19 07:13:31)

seniorgeek

Member

Registered: 2022-04-08

Posts: 4

Re: [SOLVED] SORT OF ...cryptsetup error

frostschutz
I want to thank you for all of your replies and info.  I also want to provide an update

I noticed yesterday that there was an update to archinstall and I thought I would give it a try.  It worked!  I have a usable Arch system.

I looked through the changes to the archInstall script and didn't see anything obvious that would have made things work.  I did notice that the script uses luks2 to encrypt the partition.  I have verified that my new system is using luks2  and not luks1.

Even though I have a usable system, I still don't understand why it didn't work before and why it works now.  WRT the corruption you discussed, if that was the cause of the previous failures, I don't know what caused the corruption or what "fixed" it. 

BTW, I did make a copy of the header.  Hopefully, if the corruption returns, I will be able to restore the drive.