cryptsetup - No key available with this passphrase - LUKS

_dodger_ · 2023-03-02 13:45:17

Hi,

I am using the Arch ISO from the beginning of March 2023 so it's brand new.

2 root@archiso ~ # uname -a
Linux archiso 6.2.1-arch1-1 #1 SMP PREEMPT_DYNAMIC Sun, 26 Feb 2023 03:39:23 +0000 x86_64 GNU/Linux

This is my problem in the TLDR version:

root@archiso ~ # echo 'a' | cryptsetup  luksFormat --batch-mode /dev/nvme0n1p5 -
root@archiso ~ # echo 'a' | cryptsetup luksOpen /dev/nvme0n1p5 cryptroot -
No key available with this passphrase.

This used to work and now it doesn't. The system or ISO haven't changed, the partition is newly created:

Disk /dev/nvme0n1: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: WDS200T1X0E-00AFY0
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 4468378F-0C43-4E08-A042-17E10464878A

Device             Start       End   Sectors  Size Type
/dev/nvme0n1p1      2048   4196351   4194304    2G EFI System
/dev/nvme0n1p2   4196352   4229119     32768   16M Microsoft reserved
/dev/nvme0n1p3   4229120 979460095 975230976  465G Microsoft basic data
/dev/nvme0n1p4 979460096 980756479   1296384  633M Windows recovery environment

Command (m for help): n
Partition number (5-128, default 5):
First sector (980756480-3907029134, default 980756480):
Last sector, +/-sectors or +/-size{K,M,G,T,P} (980756480-3907029134, default 3907028991):

Created a new partition 5 of type 'Linux filesystem' and of size 1.4 TiB.
Partition #5 contains a crypto_LUKS signature.

Do you want to remove the signature? [Y]es/[N]o: Y

The signature will be removed by a write command.

Command (m for help): write
The partition table has been altered.
Calling ioctl() to re-read partition table.
Syncing disks.

fdisk output after creating the partition:

root@archiso ~ # fdisk -l
Disk /dev/nvme0n1: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: WDS200T1X0E-00AFY0
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 4468378F-0C43-4E08-A042-17E10464878A

Device             Start        End    Sectors  Size Type
/dev/nvme0n1p1      2048    4196351    4194304    2G EFI System
/dev/nvme0n1p2   4196352    4229119      32768   16M Microsoft reserved
/dev/nvme0n1p3   4229120  979460095  975230976  465G Microsoft basic data
/dev/nvme0n1p4 979460096  980756479    1296384  633M Windows recovery environment
/dev/nvme0n1p5 980756480 3907028991 2926272512  1.4T Linux filesystem

luksFormat in debug mode:

root@archiso ~ # echo 'a' | cryptsetup  luksFormat --debug --batch-mode -y /dev/nvme0n1p5 -d -
# cryptsetup 2.6.1 processing "cryptsetup luksFormat --debug --batch-mode -y /dev/nvme0n1p5 -d -"
# Verifying parameters for command luksFormat.
# Running command luksFormat.
# Installing SIGINT/SIGTERM handler.
# Unblocking interruption on signal.
# Allocating context for crypt device /dev/nvme0n1p5.
# Trying to open and read device /dev/nvme0n1p5 with direct-io.
# Initialising device-mapper backend library.
Can't do passphrase verification on non-tty inputs.
# STDIN descriptor passphrase entry requested.
# Crypto backend (OpenSSL 3.0.8 7 Feb 2023 [default][legacy]) initialized in cryptsetup library version 2.6.1.
# Detected kernel Linux 6.2.1-arch1-1 x86_64.
# PBKDF argon2id, time_ms 2000 (iterations 0), max_memory_kb 1048576, parallel_threads 4.
# Formatting device /dev/nvme0n1p5 as type LUKS2.
# Auto-detected optimal encryption sector size for device /dev/nvme0n1p5 is 512 bytes.
# Topology: IO (512/0), offset = 0; Required alignment is 1048576 bytes.
# Checking if cipher aes-xts-plain64 is usable.
# Using userspace crypto wrapper to access keyslot area.
# Formatting LUKS2 with JSON metadata area 12288 bytes and keyslots area 16744448 bytes.
# Creating new digest 0 (pbkdf2).
# Setting PBKDF2 type key digest 0.
# Running pbkdf2(sha256) benchmark.
# PBKDF benchmark: memory cost = 0, iterations = 3640888, threads = 0 (took 9 ms)
# PBKDF benchmark: memory cost = 0, iterations = 3495253, threads = 0 (took 150 ms)
# PBKDF benchmark: memory cost = 0, iterations = 3483641, threads = 0 (took 602 ms)
# Benchmark returns pbkdf2(sha256) 3483641 iterations, 0 memory, 0 threads (for 512-bits key).
# Segment 0 assigned to digest 0.
# Device size 1498251526144, offset 16777216.
# Wiping LUKS areas (0x000000 - 0x1000000) with zeroes.
# Wiping keyslots area (0x008000 - 0x1000000) with random data.
# Reusing open rw fd on device /dev/nvme0n1p5
# Device size 1498251526144, offset 16777216.
# Acquiring write lock for device /dev/nvme0n1p5.
# Opening lock resource file /run/cryptsetup/L_259:15
# Verifying lock handle for /dev/nvme0n1p5.
# Device /dev/nvme0n1p5 WRITE lock taken.
# Trying to write LUKS2 header (16384 bytes) at offset 0.
# Reusing open rw fd on device /dev/nvme0n1p5
# Checksum:e28bc1af6f8e60c6111b1287de0b6e3a0e49358de1735d7e603a51249f43539f (in-memory)
# Trying to write LUKS2 header (16384 bytes) at offset 16384.
# Reusing open rw fd on device /dev/nvme0n1p5
# Checksum:64078bdc3a7527bfe748522e15c3f2427ab5c9f8d168b97ab3035386dadb2bc1 (in-memory)
# Device /dev/nvme0n1p5 WRITE lock released.
# Adding new keyslot -1 by passphrase, volume key provided by key (-1).
# Selected keyslot 0.
# Keyslot 0 assigned to digest 0.
# Trying to allocate LUKS2 keyslot 0.
# Found area 32768 -> 290816
# Running argon2id() benchmark.
# PBKDF benchmark: memory cost = 65536, iterations = 4, threads = 4 (took 36 ms)
# PBKDF benchmark: memory cost = 455111, iterations = 4, threads = 4 (took 222 ms)
# PBKDF benchmark: memory cost = 512512, iterations = 4, threads = 4 (took 247 ms)
# PBKDF benchmark: memory cost = 518736, iterations = 4, threads = 4 (took 250 ms)
# PBKDF benchmark: memory cost = 1048576, iterations = 15, threads = 4 (took 1872 ms)
# PBKDF benchmark: memory cost = 1048576, iterations = 16, threads = 4 (took 1991 ms)
# Benchmark returns argon2id() 16 iterations, 1048576 memory, 4 threads (for 512-bits key).
# Calculating attributes for LUKS2 keyslot 0.
# Acquiring write lock for device /dev/nvme0n1p5.
# Opening lock resource file /run/cryptsetup/L_259:15
# Verifying lock handle for /dev/nvme0n1p5.
# Device /dev/nvme0n1p5 WRITE lock taken.
# Checking context sequence id matches value stored on disk.
# Reusing open ro fd on device /dev/nvme0n1p5
# Running keyslot key derivation.
# Updating keyslot area [0x8000].
# Reusing open rw fd on device /dev/nvme0n1p5
# Device size 1498251526144, offset 16777216.
# Device /dev/nvme0n1p5 WRITE lock already held.
# Trying to write LUKS2 header (16384 bytes) at offset 0.
# Reusing open rw fd on device /dev/nvme0n1p5
# Checksum:a77d2382f7c79354c04778a3600264fc4275686e1e32f6d83c535ecfdb7fac86 (in-memory)
# Trying to write LUKS2 header (16384 bytes) at offset 16384.
# Reusing open rw fd on device /dev/nvme0n1p5
# Checksum:32192a11bec3e8d6b8e09f25f7cc3d41341f0511a0b530ac610396e1d1c00eb4 (in-memory)
# Device /dev/nvme0n1p5 WRITE lock released.
Key slot 0 created.
# Releasing crypt device /dev/nvme0n1p5 context.
# Releasing device-mapper backend.
# Closing read only fd for /dev/nvme0n1p5.
# Closing read write fd for /dev/nvme0n1p5.
Command successful.

luksOpen in debug mode:

root@archiso ~ # echo 'a' | cryptsetup luksOpen --debug /dev/nvme0n1p5 cryptroot -
# cryptsetup 2.6.1 processing "cryptsetup luksOpen --debug /dev/nvme0n1p5 cryptroot -"
# Verifying parameters for command open.
# Running command open.
# Installing SIGINT/SIGTERM handler.
# Unblocking interruption on signal.
# Allocating context for crypt device /dev/nvme0n1p5.
# Trying to open and read device /dev/nvme0n1p5 with direct-io.
# Initialising device-mapper backend library.
# Trying to load any crypt type from device /dev/nvme0n1p5.
# Crypto backend (OpenSSL 3.0.8 7 Feb 2023 [default][legacy]) initialized in cryptsetup library version 2.6.1.
# Detected kernel Linux 6.2.1-arch1-1 x86_64.
# Loading LUKS2 header (repair disabled).
# Acquiring read lock for device /dev/nvme0n1p5.
# Opening lock resource file /run/cryptsetup/L_259:15
# Verifying lock handle for /dev/nvme0n1p5.
# Device /dev/nvme0n1p5 READ lock taken.
# Trying to read primary LUKS2 header at offset 0x0.
# Opening locked device /dev/nvme0n1p5
# Verifying locked device handle (bdev)
# LUKS2 header version 2 of size 16384 bytes, checksum sha256.
# Checksum:a77d2382f7c79354c04778a3600264fc4275686e1e32f6d83c535ecfdb7fac86 (on-disk)
# Checksum:a77d2382f7c79354c04778a3600264fc4275686e1e32f6d83c535ecfdb7fac86 (in-memory)
# Trying to read secondary LUKS2 header at offset 0x4000.
# Reusing open ro fd on device /dev/nvme0n1p5
# LUKS2 header version 2 of size 16384 bytes, checksum sha256.
# Checksum:32192a11bec3e8d6b8e09f25f7cc3d41341f0511a0b530ac610396e1d1c00eb4 (on-disk)
# Checksum:32192a11bec3e8d6b8e09f25f7cc3d41341f0511a0b530ac610396e1d1c00eb4 (in-memory)
# Device size 1498251526144, offset 16777216.
# Device /dev/nvme0n1p5 READ lock released.
# PBKDF argon2id, time_ms 2000 (iterations 0), max_memory_kb 1048576, parallel_threads 4.
# Activating volume cryptroot using token (any type) -1.
# dm version   [ opencount flush ]   [16384] (*1)
# dm versions   [ opencount flush ]   [16384] (*1)
# Detected dm-ioctl version 4.47.0.
# Device-mapper backend running with UDEV support enabled.
# dm status cryptroot  [ opencount noflush ]   [16384] (*1)
No usable token is available.
# STDIN descriptor passphrase entry requested.
# Activating volume cryptroot [keyslot -1] using passphrase.
# dm versions   [ opencount flush ]   [16384] (*1)
# dm status cryptroot  [ opencount noflush ]   [16384] (*1)
# Keyslot 0 priority 1 != 2 (required), skipped.
# Trying to open LUKS2 keyslot 0.
# Running keyslot key derivation.
# Reading keyslot area [0x8000].
# Acquiring read lock for device /dev/nvme0n1p5.
# Opening lock resource file /run/cryptsetup/L_259:15
# Verifying lock handle for /dev/nvme0n1p5.
# Device /dev/nvme0n1p5 READ lock taken.
# Reusing open ro fd on device /dev/nvme0n1p5
# Device /dev/nvme0n1p5 READ lock released.
# Verifying key from keyslot 0, digest 0.
# Digest 0 (pbkdf2) verify failed with -1.
No key available with this passphrase.
# Releasing crypt device /dev/nvme0n1p5 context.
# Releasing device-mapper backend.
# Closing read only fd for /dev/nvme0n1p5.
Command failed with code -2 (no permission or bad passphrase).

luksDump:

130 root@archiso ~ # cryptsetup luksDump /dev/nvme0n1p5
LUKS header information
Version:        2
Epoch:          3
Metadata area:  16384 [bytes]
Keyslots area:  16744448 [bytes]
UUID:           cea31415-b712-4863-9948-b71171b8484a
Label:          (no label)
Subsystem:      (no subsystem)
Flags:          (no flags)

Data segments:
  0: crypt
        offset: 16777216 [bytes]
        length: (whole device)
        cipher: aes-xts-plain64
        sector: 512 [bytes]

Keyslots:
  0: luks2
        Key:        512 bits
        Priority:   normal
        Cipher:     aes-xts-plain64
        Cipher key: 512 bits
        PBKDF:      argon2id
        Time cost:  16
        Memory:     1048576
        Threads:    4
        Salt:       59 d1 0d e2 4d e4 09 e9 e0 fe df a0 d2 04 60 66
                    a0 1b 68 6f 5b 56 ac 98 90 f1 99 d3 a0 af 83 57
        AF stripes: 4000
        AF hash:    sha256
        Area offset:32768 [bytes]
        Area length:258048 [bytes]
        Digest ID:  0
Tokens:
Digests:
  0: pbkdf2
        Hash:       sha256
        Iterations: 442810
        Salt:       c6 03 98 1a 7a b4 9b 79 50 ee c1 c5 8b ce e8 21
                    0d 12 4d cb f0 37 54 a9 7a 24 34 c7 99 2b de a8
        Digest:     9c 63 5a d5 f5 17 77 0e 82 0f 94 5c 33 3a 57 d9
                    b3 e1 dc 71 45 f2 5d a4 56 e3 c9 ec ce f5 64 8b

I did export the header, sent it to a friend who tried to open the header on his machine, doesn't work either.
In other words: Something is wrong with the header but I have no idea what.

frostschutz · 2023-03-02 15:46:52

_dodger_ wrote:

This is my problem in the TLDR version:

root@archiso ~ # echo 'a' | cryptsetup  luksFormat --batch-mode /dev/nvme0n1p5 -
root@archiso ~ # echo 'a' | cryptsetup luksOpen /dev/nvme0n1p5 cryptroot -
No key available with this passphrase.

You are formatting it with key 'a\n' but trying to open it with key 'a'. That happens despite passing the same echo a, because cryptsetup interprets it different ways.

The syntax for luksFormat is luksFormat <device> [<key file>] by passing - as keyfile, it treats stdin as keyfile, and for keyfiles it retains line breaks.

The syntax for luksOpen is luksOpen <device> <name> if you want to pass - as a key file you need --key-file=- parameter. Adding - after cryptroot does not have the same meaning as when you luksFormat.

So in your example you are not using key-file method, and cryptsetup stops reading when it encounters \n. It tries to open with 'a' when it needed 'a\n' so there is no key available with this passphrase.

You can read more about this issue in man cryptsetup, Passphrase processing for LUKS

Ideally your keys would be strings where it does not matter whether you type them on the keyboard, or as keyfile, or stdin - they would be interpreted the same way. Since that is not how cryptsetup works by default, you can only achieve it by avoiding special characters and newlines in keyfiles.

Use `echo -n text` or `printf "%s" text` to print strings without newlines.

If you must use random binary data as a key, make sure it's always passed through the key-file and not as stdin, since stdin stops reading after newline so your key is a lot shorter than you expect, worst case empty if first byte is \n

Last edited by frostschutz (2023-03-02 15:55:06)

_dodger_ · 2023-03-02 21:15:08

Thank you very much.
Unfortunately, I did more damage by trying to provide a minimal example than it did good.

I did run the commands from my example but we do have an explanation now why they don't work.

What triggered all of this though as that this also happens when I just run those commands and enter the character "a" (or any other string) manually and then press enter.
I tried to make it easier to reproduce by using the "echo" method but I see now that was not a good idea. Sorry for the confusion.

I still face the same problem I'm afraid.

I did a new test:

1. cat /dev/zero | wcs > /dev/nvme0n1p5
This actually gave a kernel error after writing 500GB / unable to handle page fault for address ..... but I'm going to assume that this is unrelated for now as I assume cryptsetup doesn't care about something 500GB down the line when opening)

2. wipefs /dev/nvme0n1p5 -> Empty

3. cryptsetup luksFormat /dev/nvme0n1p5 -> Manually hit the "a" key followed by enter, verify a second time. All good

4. # wipefs /dev/nvme0n1p5
DEVICE OFFSET TYPE UUID LABEL
nvme0n1p5 0x0 crypto_LUKS 695c4fc2-9d95-4460-b9cd-9933803d176b
nvme0n1p5 0x4000 crypto_LUKS 695c4fc2-9d95-4460-b9cd-9933803d176b

From all I read it is normal to have two signatures (secondary)

5. cryptsetup luksOpen, manually press "a" and the same error "No key available with this passphrase"

I honestly don't understand what the problem could be. All of this did
work last week and it did work _once_ earlier today for some reason but then never again.
I checked smartctl to make sure that the hard drive is not reporting any errors.

I also tried this with an Ubuntu USB stick now which has cryptsetup 2.5.0, same error.

Can you think of _anything_ else to try? I'm a bit desperate

frostschutz · 2023-03-02 22:08:48

Can you think of _anything_ else to try? I'm a bit desperate

Did you check dmesg for any error messages? What does your /proc/cpuinfo look like? Does cryptsetup benchmark work?

You can remove storage from the equation by testing it in a ram based device:

# tmpfs so no physical storage is involved
mkdir /mnt/tmpfs
mount none -t tmpfs /mnt/tmpfs
cd /mnt/tmpfs

# luks container file
truncate -s 100M foobar.img
cryptsetup luksFormat foobar.img
cryptsetup luksOpen foobar.img foobar

If that works, then you can copy the luks header to your physical storage. Then test it again on the physical storage. Then if it does not work from physical storage, you can 'cmp -l foobar.img /dev/partition' to see if it got corrupted or what.

If you're not able to open a LUKS container at all, usually it's either the wrong passphrase ('a' vs 'a\n' in first example) or damaged key material.

This could be a bad ram issue, storage issue, some other process writing to storage and thus corrupting it, ... it could also be a bug in cryptsetup or any of the libraries its using. On a livecd/chroot it could also be kernel related or missing modules, although that would be more about being unable to open it, since loading modules from within chroot is a problem...

There was someone with the same issue https://bbs.archlinux.org/viewtopic.php?id=281320 unfortunately they never reported back... so it remains a mystery.

cryptsetup does not like odd partition sizes (must be multiple of 4096 bytes) but that complains about ioctls invalid arguments, not "no key with this passphrase"...

Is your system very constrained for available memory? There was a bug that caused luksFormat to die (out of memory) - https://gitlab.com/cryptsetup/cryptsetup/-/issues/802 but I assume if this was your problem, the luksDump would look different

_dodger_ · 2023-03-02 22:15:59

Thanks for the additional hints!

I believe I found the problem: memtest reported memory errors (so you were spot on!), I found this comment which made me run it https://github.com/systemd/systemd/issu … -636415564

To further complicate this, I did run a BIOS update yesterday morning and yesterday evening tried to install Arch, I didn't make the connection.
I had to enable AMD EXPO mode once and now everything seems to work fine.

I am still uncertain whether it's a hardware issue or a BIOS problem but it definitely does not seem to be a cryptsetup issue.

Thank you for your input. I learned a lot today and your tmpfs idea is a good one!

Arch Linux

#1 2023-03-02 13:45:17

cryptsetup - No key available with this passphrase - LUKS

#2 2023-03-02 15:46:52

Re: cryptsetup - No key available with this passphrase - LUKS

#3 2023-03-02 21:15:08

Re: cryptsetup - No key available with this passphrase - LUKS

#4 2023-03-02 22:08:48

Re: cryptsetup - No key available with this passphrase - LUKS

#5 2023-03-02 22:15:59

Re: cryptsetup - No key available with this passphrase - LUKS

Board footer