"No key available with this passphrase" with a newly-created DM-CRYPT / LUKS partition

encryption luks cryptsetup

8,015

TL;DR - Check if the media is reliable; luksFormat and luksOpen don't.

The problem could be thought of in at least a few ways:

The wrong passphrase is being provided
The passphrase is being given in the wrong way
Something is wrong with essential software, like cryptsetup itself.

Out of curiosity, I decided to do a complete format of the mmc drive (to "start from scratch), but with checking:

sudo mkfs.ext4 /dev/mmcblk0 -cc   

mke2fs 1.44.4 (18-Aug-2018)
/dev/mmcblk0 contains a ext4 file system
        last mounted on Tue Mar  5 11:30:02 2019
Proceed anyway? (y,N) y
Discarding device blocks: done                            
Creating filesystem with 15591936 4k blocks and 3899392 inodes
Filesystem UUID: 0ab72f40-d2a2-408d-b4ca-d5e8fcc27ec7
Superblock backups stored on blocks: 
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
        4096000, 7962624, 11239424

Testing with pattern 0xaa: done                                                 
Reading and comparing: done                                                 
Testing with pattern 0x55: done                                                 rs)
Reading and comparing: done                                                 rs)
Testing with pattern 0xff: done                                                 rs)
Reading and comparing: done                                                 rs)
Testing with pattern 0x00: done                                                 rs)
Reading and comparing: done                                                 rs)
Block 0 in primary superblock/group descriptor area bad.
Blocks 0 through 9 must be good in order to build a filesystem.
Aborting....

I could already see where this was going..

Since I've never formatted like that before, I formatted a second storage device (a USB stick) with checking, and it's format concluded successfully. Going through the same cryptsetup process to format and open that USB stick worked. This reveals another problem that was happening:

The passphrase is being received in the wrong way

I suspect that luksFormat isn't doing any sanity checking to see that its data can actually be read.

As a followup, I had already done a non-quick format under Windows and it worked fine. I also performed a complete write-read-compare test and it was also a success. I have other tests to perform, just out of curiosity, but this may well (somehow) be a Linux-specific issue. I won't troubleshoot down that rabbit hole, but I'll conclude that it's important to do all the formatting and testing on the specific platform the issue is seen on.

8,015

spiralofhope

http://blog.spiralofhope.com/?p=11563

Updated on September 18, 2022

Comments

spiralofhope over 1 year
Doing searches, it appears that others are having more complex problems because of cipher settings, but my problem is when doing something straightforward.

Using a mostly-fresh install of Lubuntu 18.10 32bit (the kernel has been updated), I can create an encrypted partition thusly:
```
cryptsetup  --verbose  --verify-passphrase  luksFormat  /dev/mmcblk0    

WARNING: Device /dev/mmcblk0 already contains a 'crypto_LUKS' superblock signature.

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

Are you sure? (Type uppercase yes): YES
Enter passphrase for /dev/mmcblk0: 
Verify passphrase: 
Existing 'crypto_LUKS' superblock signature on device /dev/mmcblk0 will be wiped.
Key slot 0 created.
Command successful.
```
If the password given is the letter a, I am unable to unlock it thusly:
```
cryptsetup  --verbose  luksOpen  /dev/mmcblk0 crypt

Enter passphrase for /dev/mmcblk0:
No key available with this passphrase.
Enter passphrase for /dev/mmcblk0:
```
(I also tried zulucrypt with the same result)

Since I installed Lubuntu using its installer's encryption functionality, I can do a comparison between what my system is using natively, and what cryptsetup made on my mmc drive.
```
cryptsetup luksDump /dev/sda1
```
The relevant part appears to be:
```
Version:        1
Cipher name:    aes
Cipher mode:    xts-plain64
Hash spec:      sha256
Payload offset: 4096
MK bits:        512
```
The only difference I see between the two dumps is that for my local drive, the bottom "MK bits" is 512, but for the mmc it is 256.

I don't know if it's relevant, but I also see that my local drive has two key slots and the mmc has only one. (The fact that my local drive has two key slots makes me hope/wonder if the installer put in a duplicate key in case the first is corrupt.)

A commenter asked me to try providing a passphrase this way:
```
echo -n 'a' | cryptsetup  --verbose  luksOpen  /dev/mmcblk0 crypt

Can't do passphrase verification on non-tty inputs.
No key available with this passphrase.
Command failed with code -2 (no permission or bad passphrase).
```
Another way to provide a password:
```
echo 'a' > interactive_pass         
cat interactive_pass | cryptsetup luksAddKey /dev/mmcblk0

No key available with this passphrase.
```
Using a keyfile.

I can't comprehend this. I fumbled around for a while, but stopped because I can't tell the difference between using it wrong and it having its own issues.

zulucrypt has a way to create a keyfile, but it just says Failed To Generate Key. It's straightforward, so I'm certain I'm using it correctly (ran as root, have write permissions to the file which I'd like to create)
- Xen2050 about 5 years
  
  Should definitely be able to open/unlock a device immediately after creating it, as long as the right password's being typed. Try checking using a keyfile, or perhaps echo -n "password" | cryptsetup luksOpen ...
- spiralofhope about 5 years
  
  The echo did not work (I tried two ways). I don't understand keyfiles, and my attempts have failed. I'll try a GUI tool for a keyfile.
- spiralofhope about 5 years
  
  zulucrypt can't make a keyfile. The instructions I've been trying to muddle through aren't working either, and I don't want to use a key file any way.
- Xen2050 about 5 years
  
  Not sure why you've got a "non-tty input", are you in a regular bash terminal? And if you do try a keyfile, just to verify you're creating a device & later can open it with the same passphrase, don't just cat & pipe it to cryptsetup (since the similar echo already failed) but use the --key-file option
- spiralofhope about 5 years
  
  Yes I'm in a regular terminal (X, qterminal, zsh). I already experimented with some key file stuff. It's opaque to me, but I'll try harder.
- spiralofhope about 5 years
  
  Well shoot, the media was bad and cryptsetup was being as dumb as a sack of bricks.
Xen2050 about 5 years

I think LuksFormat only writes 1M or 2M for it's header at the start of the device, so it must have thought that went "good enough"...? Still weird how it couldn't be opened, but a bad device leads to all sorts of problems