Arch Linux

ce1984

Member

Registered: 2014-01-24

Posts: 41

cryptsetup rejecting passphrase on devices created with --use-random

Hi all, I've encountered a problem that I'm not really certain where to start - but I think it likely that I'm looking at a hardware issue.

Basically, I had been running an arch system with full disk encryption, using a luks volume on a SSD mounted to /, and a separate luks volume on a HDD, mounted to /home via crypttab. The other day, after doing a system update, after entering the passphrase I'm greeted with 'No key available for this passphrase'. I've made absolutely certain that I've typed it correctly. I tried mounting it with cryptsetup open from an arch live USB, same result.

Since this was a fairly new install anyway (and everything important was backed up elsewhere) I decided to just wipe everything and start over. Now I'm at the stage where I'm encrypting the root partition, and then trying to map it to proceed with the installation. It still won't accept the passphrase. Basically:

# cryptsetup luksFormat --use-random /dev/nvme0n1p2
Enter passphrase for /dev/nvme0n1p2: test
Verify passphrase: test
#cryptsetup open /dev/nvme0n1p2 cryptroot
Enter passphrase for /dev/nvme0n1p2: test
No key available for this passphrase.

Any ideas where to start figuring this out? Issue with the SSD possibly?

Thanks

EDIT: So I just tried this omitting --use-random and it seems to work fine. I know /dev/random is much slower, but I would expect the operation to just take longer, not create an unopenable device. I though maybe just a coincidence but I've tried it a few times each way now, I can't open any device created with --use-random.

Last edited by ce1984 (2020-08-16 18:30:46)

twelveeighty

Member

Registered: 2011-09-04

Posts: 1,448

Re: cryptsetup rejecting passphrase on devices created with --use-random

If your workaround works, please update the title and contents of your post to reflect that your problem is with --use-random instead so people can help you with the actual problem quicker.

GaKu999

Member

From: US/Eastern

Registered: 2020-06-21

Posts: 696

Re: cryptsetup rejecting passphrase on devices created with --use-random

Can’t replicate...

Btw random and urandom as of a recent kernel update (something around 5.7 maybe?) are pretty much the same....(well not the same, but not anymore as mythical as most people remember them)
What kernel are you using?

Attempt to test it on a tiny img on /tmp (256MB should be alright) to see if it replicates...

---

My repos • Some snippets

Heisenberg might have been here.

ce1984

Member

Registered: 2014-01-24

Posts: 41

Re: cryptsetup rejecting passphrase on devices created with --use-random

So I tried this with an image as suggested and was unable to replicate. Then I went back and tried it again with the SSD and this time everything works fine, no issues at all. Very strange. I think I'm going to proceed with reinstalling the system like it was before, except this time I'm going to make a few changes. Please let me know if there's anything else I should do in this process to make this easier to diagnose if this problem shows up again. What I'm planning now:

Make LUKS header backups right away.
Run hardware stress tests after installation to see if I have a memory issue or something
Mirror the SSD to an image file
Add a keyslot for a short password at first to make diagnostics easier (I can't tell you how many times I retyped my passphrase thinking I just made a typo)

Thanks

ce1984

Member

Registered: 2014-01-24

Posts: 41

Re: cryptsetup rejecting passphrase on devices created with --use-random

More weirdness: When I tried to create a new filesystem on the mapped device:

#mkfs.ext4 /dev/mapper/cryptroot
mke2fs 1.45.4 (23-Sep-2019)
/dev/mapper/cryptroot contains 'PARIX object' data
Proceed anyway? (y/N)

The phrase "PARIX object data" appears exactly once on google. What is going on here?

GaKu999

Member

From: US/Eastern

Registered: 2020-06-21

Posts: 696

Re: cryptsetup rejecting passphrase on devices created with --use-random

I...do not know what is that, did you make a new LUKS or are you still using one that previously contained a filesystem?

Generally when people create a LUKS it’s recommended do to a wipe of the data (also important but difficult to do on a SSD...), maybe remanent data?

What I do (I have HDDs...), after I create a LUKS, I unlock the crypt and run:

dd if=/dev/zero of=/dev/mapper/<namehere> bs=4096 status=progress

OR

cat /dev/zero /dev/mapper/<namehere>

Since it’s unlocked it gets filled with zeroes but those zeroes are ciphered on storage, btw that’s what the cryptsetup FAQ says...

I choose dd because of the status progress but you can choose any alternative that works for you...also you could use a different value for bs like 8192...

Also simple advice yet best advice, it’s always nice to take a read at the manpages with ‘man <command>‘ ,that way you’ll know what each command/parameter does.

---

My repos • Some snippets

Heisenberg might have been here.

frostschutz

Member

Registered: 2013-11-15

Posts: 1,640

Re: cryptsetup rejecting passphrase on devices created with --use-random

More weirdness: When I tried to create a new filesystem on the mapped device:

#mkfs.ext4 /dev/mapper/cryptroot
mke2fs 1.45.4 (23-Sep-2019)
/dev/mapper/cryptroot contains 'PARIX object' data
Proceed anyway? (y/N)

It's normal:

$ while file -s /dev/urandom; do :; done | grep -v ': data'
/dev/urandom: COM executable for DOS
/dev/urandom: SVR2 pure executable (USS/370) not stripped - version 488602529
/dev/urandom: PGP Secret Key -
/dev/urandom: DOS executable (COM, 0x8C-variant)
/dev/urandom: PARIX T9000 object not stripped
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
/dev/urandom: SysEx File - Victor
/dev/urandom: DOS executable (COM, 0x8C-variant)
/dev/urandom: COM executable for DOS
/dev/urandom: PGP Secret Key -
/dev/urandom: MPEG-4 LOAS
/dev/urandom: PGP Secret Sub-key -
/dev/urandom: SysEx File -
/dev/urandom: very old 16-bit-int big-endian archive
/dev/urandom: little endian ispell 3.1 hash file,
/dev/urandom: Macintosh HFS Extended version 59270 data (mounted) (unclean) last mounted by: '\201', created: Fri Apr  6 05:24:20 2018, last modified: Sat Jan 31 06:33:33 1976, last backup: Sat Jan  4 02:41:38 1997, block size: -1435861454, number of blocks: 1549597172, free blocks: 796298257
/dev/urandom: SysEx File -

Some file magics have just two or three bytes. It's possible for those to appear randomly.

Encryption gives you random data, and it's possible for that to be misidentified as something else.