cryptsetup - No key available with passphrase

cryptsetup - No key available with passphrase

[Lars Francke]

Hello,

I am trying to setup LUKS (and I've done it like this in the past,
like...two weeks ago and it just stopped working) and am running into
the following issue:

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.

I have included all the debug output below, I also extracted the
header and uploaded it here:
https://drive.google.com/file/d/1-NhDbjZM0c29Mbt0_XEfx4yYzWwy0IyE/view?usp=sharing

This is on an ISO from Arch Linux from March 2023.

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

--------------------------------------------------

I created the partition from scratch:

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:

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


This can only be a stupid minor thing.
Almost all search results basically say that the keyboard layout is
wrong or a keyboard is broken or whatever but I'm 100% certain that
this is not the case here.
I would appreciate any help.

Thank you very much.

Cheers,
Lars

Re: cryptsetup - No key available with passphrase

[Milan Broz]

On 3/2/23 15:03, Lars Francke wrote:
> Hello,
> 
> I am trying to setup LUKS (and I've done it like this in the past,
> like...two weeks ago and it just stopped working) and am running into
> the following issue:
> 
> 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 is just a little bit confusing handling of end-of-line if used with "-"
(see section "Passphrase processing for LUKS" in man cryptsetup).

The first command will create passphrase "a\n" (including \n !) while the second
command will process only "a" (you can to use --key-file=- there for luksOpen,
it has different syntax.)

But just do not use "-" here, cryptsetup will do what needed automatically.
Also batch mode is implicit if it detects pipe input, so just use:

# echo 'a' | cryptsetup luksFormat /dev/nvme0n1p5
# echo 'a' | cryptsetup luksOpen /dev/nvme0n1p5 cryptroot

and it should work as expected (password will be "a").

Milan

Re: cryptsetup - No key available with passphrase

[Lars Francke]

Milan,

thank you for the quick reply. I did try that but unfortunately:

root@archiso ~ # echo 'a' | cryptsetup luksFormat /dev/nvme0n1p5
WARNING: Device /dev/nvme0n1p5 already contains a 'crypto_LUKS'
superblock signature.
root@archiso ~ # echo 'a' | cryptsetup luksOpen /dev/nvme0n1p5 cryptroot
No key available with this passphrase.


I also just used the `echo` method to make it easier to replicate.
The same happens when I just press "a" on my keyboard and hit enter.

What makes it even weirder is that it did work _once_:

# echo 'a' | cryptsetup luksFormat /dev/nvme0n1p5
WARNING: Device /dev/nvme0n1p5 already contains a 'crypto_LUKS'
superblock signature.
# echo 'a' | cryptsetup luksOpen /dev/nvme0n1p5 cryptroot

I'm at a loss but will now read the section in the man page that you
referred to.

Thanks again,
Lars
On Thu, Mar 2, 2023 at 4:01 PM Milan Broz <gmazyland@gmail.com> wrote:
>
> On 3/2/23 15:03, Lars Francke wrote:
> > Hello,
> >
> > I am trying to setup LUKS (and I've done it like this in the past,
> > like...two weeks ago and it just stopped working) and am running into
> > the following issue:
> >
> > 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 is just a little bit confusing handling of end-of-line if used with "-"
> (see section "Passphrase processing for LUKS" in man cryptsetup).
>
> The first command will create passphrase "a\n" (including \n !) while the second
> command will process only "a" (you can to use --key-file=- there for luksOpen,
> it has different syntax.)
>
> But just do not use "-" here, cryptsetup will do what needed automatically.
> Also batch mode is implicit if it detects pipe input, so just use:
>
> # echo 'a' | cryptsetup luksFormat /dev/nvme0n1p5
> # echo 'a' | cryptsetup luksOpen /dev/nvme0n1p5 cryptroot
>
> and it should work as expected (password will be "a").
>
> Milan

Re: cryptsetup - No key available with passphrase

[Milan Broz]

On 3/2/23 17:23, Lars Francke wrote:
> Milan,
> 
> thank you for the quick reply. I did try that but unfortunately:
> 
> root@archiso ~ # echo 'a' | cryptsetup luksFormat /dev/nvme0n1p5
> WARNING: Device /dev/nvme0n1p5 already contains a 'crypto_LUKS'
> superblock signature.
> root@archiso ~ # echo 'a' | cryptsetup luksOpen /dev/nvme0n1p5 cryptroot
> No key available with this passphrase.
> 
> 
> I also just used the `echo` method to make it easier to replicate.
> The same happens when I just press "a" on my keyboard and hit enter.
> 
> What makes it even weirder is that it did work _once_:

Did you deactivate the device once it succeeded?

Anyway, it should work as I described. Maybe you should wipe the
signature before format with "wipefs -a /dev/nvme0n1p5" (but it should
overwrite it anyway or print error).

You can also use --test-passphrase to luksOpen to avoid activation.

Milan

> 
> # echo 'a' | cryptsetup luksFormat /dev/nvme0n1p5
> WARNING: Device /dev/nvme0n1p5 already contains a 'crypto_LUKS'
> superblock signature.
> # echo 'a' | cryptsetup luksOpen /dev/nvme0n1p5 cryptroot
> 
> I'm at a loss but will now read the section in the man page that you
> referred to.



> 
> Thanks again,
> Lars
> On Thu, Mar 2, 2023 at 4:01 PM Milan Broz <gmazyland@gmail.com> wrote:
>>
>> On 3/2/23 15:03, Lars Francke wrote:
>>> Hello,
>>>
>>> I am trying to setup LUKS (and I've done it like this in the past,
>>> like...two weeks ago and it just stopped working) and am running into
>>> the following issue:
>>>
>>> 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 is just a little bit confusing handling of end-of-line if used with "-"
>> (see section "Passphrase processing for LUKS" in man cryptsetup).
>>
>> The first command will create passphrase "a\n" (including \n !) while the second
>> command will process only "a" (you can to use --key-file=- there for luksOpen,
>> it has different syntax.)
>>
>> But just do not use "-" here, cryptsetup will do what needed automatically.
>> Also batch mode is implicit if it detects pipe input, so just use:
>>
>> # echo 'a' | cryptsetup luksFormat /dev/nvme0n1p5
>> # echo 'a' | cryptsetup luksOpen /dev/nvme0n1p5 cryptroot
>>
>> and it should work as expected (password will be "a").
>>
>> Milan

Re: cryptsetup - No key available with passphrase

[Lars Francke]

On Thu, Mar 2, 2023 at 5:41 PM Milan Broz <gmazyland@gmail.com> wrote:
>
> On 3/2/23 17:23, Lars Francke wrote:
> > Milan,
> >
> > thank you for the quick reply. I did try that but unfortunately:
> >
> > root@archiso ~ # echo 'a' | cryptsetup luksFormat /dev/nvme0n1p5
> > WARNING: Device /dev/nvme0n1p5 already contains a 'crypto_LUKS'
> > superblock signature.
> > root@archiso ~ # echo 'a' | cryptsetup luksOpen /dev/nvme0n1p5 cryptroot
> > No key available with this passphrase.
> >
> >
> > I also just used the `echo` method to make it easier to replicate.
> > The same happens when I just press "a" on my keyboard and hit enter.
> >
> > What makes it even weirder is that it did work _once_:
>
> Did you deactivate the device once it succeeded?

I have to admit that I'm also not entirely sure what you mean by
"deactivate" in this case.
But probably not then :)

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.
I checked smartctl to make sure that the hard drive is not reporting
any errors and it doesn't

I also tried this with an Ubuntu USB stick now which has cryptsetup 2.5.0

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

Thank you,
Lars


> Anyway, it should work as I described. Maybe you should wipe the
> signature before format with "wipefs -a /dev/nvme0n1p5" (but it should
> overwrite it anyway or print error).
>
> You can also use --test-passphrase to luksOpen to avoid activation.
>
> Milan
>
> >
> > # echo 'a' | cryptsetup luksFormat /dev/nvme0n1p5
> > WARNING: Device /dev/nvme0n1p5 already contains a 'crypto_LUKS'
> > superblock signature.
> > # echo 'a' | cryptsetup luksOpen /dev/nvme0n1p5 cryptroot
> >
> > I'm at a loss but will now read the section in the man page that you
> > referred to.
>
>
>
> >
> > Thanks again,
> > Lars
> > On Thu, Mar 2, 2023 at 4:01 PM Milan Broz <gmazyland@gmail.com> wrote:
> >>
> >> On 3/2/23 15:03, Lars Francke wrote:
> >>> Hello,
> >>>
> >>> I am trying to setup LUKS (and I've done it like this in the past,
> >>> like...two weeks ago and it just stopped working) and am running into
> >>> the following issue:
> >>>
> >>> 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 is just a little bit confusing handling of end-of-line if used with "-"
> >> (see section "Passphrase processing for LUKS" in man cryptsetup).
> >>
> >> The first command will create passphrase "a\n" (including \n !) while the second
> >> command will process only "a" (you can to use --key-file=- there for luksOpen,
> >> it has different syntax.)
> >>
> >> But just do not use "-" here, cryptsetup will do what needed automatically.
> >> Also batch mode is implicit if it detects pipe input, so just use:
> >>
> >> # echo 'a' | cryptsetup luksFormat /dev/nvme0n1p5
> >> # echo 'a' | cryptsetup luksOpen /dev/nvme0n1p5 cryptroot
> >>
> >> and it should work as expected (password will be "a").
> >>
> >> Milan

Re: cryptsetup - No key available with passphrase

[Michael Kjörling]

On 2 Mar 2023 21:34 +0100, from lars.francke@gmail.com (Lars Francke):
> 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.
> I checked smartctl to make sure that the hard drive is not reporting
> any errors and it doesn't

SMART data unfortunately is not always conclusive; particularly, it's
not always conclusive in indicating the _absence_ of a problem. Plain
and simple, storage devices _lie_, some more than others.

I would try again, but this time creating the LUKS container using a
file in a ramfs (not tmpfs, which is allowed to be swapped out) as
backing store, possibly mapped to a loopback device. Doing so will
eliminate persistent storage from the equation.

If that works, then my suspicion would be on the drive itself.

If that doesn't work either, then there's likely something problematic
about the software stack, at which point exact versions of everything
becomes interesting. Kernel, cryptsetup, libcryptsetup, ...

-- 
Michael Kjörling                     🔗 https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”

Re: cryptsetup - No key available with passphrase

[Lars Francke]

Hi Michael,

thank you very much for the ramfs idea and your input.
I would have done this next (and I still might) but it could be that I
found the issue.

I'm running more detailed tests now.
This Github issue[1] made me run a memtest and that did show errors,
but those errors went away as soon as I enabled the AMD EXPO mode to
overclock the memory.
It's the next rabbit hole I'm looking at now. But using that
overclocked memory I am able to run all the commands from this thread
successfully (at least when I tried it just now, I'll reset everything
and will try again).
Next test was disabling the EXPO mode again and it still worked and
memtest shows no errors. That is weird.
I _did_ update the BIOS yesterday. All PC components are brand new....
it worked before the BIOS update, the problems started after the BIOS
update but because there were a few hours in between I didn't make the
connection until now.

I have to admit: I did not think about memory as being a potential
problem but it makes sense that cryptsetup/LUKS/dm-crypt need a lot of
memory for some of the operations.

I'll update here should I find more.
For now I hope I have a stable configuration.

Thank you both for your help and sorry for raising this unrelated
issue - cryptsetup was probably just so early in the installation
phase, other steps would probably have failed later as well.
I can't think of anything cryptsetup could  have done to prevent this.

Cheers,
Lars


[1] <https://github.com/systemd/systemd/issues/14927#issuecomment-636415564>


On Thu, Mar 2, 2023 at 10:55 PM Michael Kjörling <152cc69a347e@ewoof.net> wrote:
>
> On 2 Mar 2023 21:34 +0100, from lars.francke@gmail.com (Lars Francke):
> > 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.
> > I checked smartctl to make sure that the hard drive is not reporting
> > any errors and it doesn't
>
> SMART data unfortunately is not always conclusive; particularly, it's
> not always conclusive in indicating the _absence_ of a problem. Plain
> and simple, storage devices _lie_, some more than others.
>
> I would try again, but this time creating the LUKS container using a
> file in a ramfs (not tmpfs, which is allowed to be swapped out) as
> backing store, possibly mapped to a loopback device. Doing so will
> eliminate persistent storage from the equation.
>
> If that works, then my suspicion would be on the drive itself.
>
> If that doesn't work either, then there's likely something problematic
> about the software stack, at which point exact versions of everything
> becomes interesting. Kernel, cryptsetup, libcryptsetup, ...
>
> --
> Michael Kjörling                     🔗 https://michael.kjorling.se
> “Remember when, on the Internet, nobody cared that you were a dog?”
>
>

Re: cryptsetup - No key available with passphrase

[Milan Broz]

Hi,

On 3/2/23 23:12, Lars Francke wrote:
> Thank you both for your help and sorry for raising this unrelated
> issue - cryptsetup was probably just so early in the installation
> phase, other steps would probably have failed later as well.
> I can't think of anything cryptsetup could  have done to prevent this.

It is related - as it is definitely only you who experienced it.

Actually it is quite interesting issue. Argon2 KDF uses a lot of memory
and any glitch (even one bit flip) will change it's output.
So memory failure explains what you see here.
(You should see this rarely if --type luks1 was used for format,
as LUKS1 does not use Argon2. But memory failure is just a recipe
for disaster later...)

Thanks,
Milan

Re: cryptsetup - No key available with passphrase

[Michael Kjörling]

On 3 Mar 2023 08:55 +0100, from gmazyland@gmail.com (Milan Broz):
> Actually it is quite interesting issue. Argon2 KDF uses a lot of memory
> and any glitch (even one bit flip) will change it's output.
> So memory failure explains what you see here.
> (You should see this rarely if --type luks1 was used for format,
> as LUKS1 does not use Argon2. But memory failure is just a recipe
> for disaster later...)

I agree. If you're seeing RAM errors on a system with non-ECC RAM, then
that's going to crop up at one point or another and bite you hard in
some hard-to-predict, difficult-to-debug and impossible-to-reproduce
manner. I'm actually surprised that if this is a RAM issue that it's as
reproducible as you reported; maybe just one memory module is bad? A
single bit stuck either as a 0 or a 1 wouldn't necessarily show up
during normal use, but something like Argon2 just might perhaps have
difficulties because of it because it's effectively an error amplifier,
and a stuck bit wouldn't necessarily cause checksum mismatches.

Consider running an extended memtest session (>24 hours or several full
passes, whichever takes longer) both after the computer has been
running for a while (and thus the components have warmed up to a
somewhat normal operating temperature), and immediately after it has
been turned off for a while, perhaps over night (allowing it to cool
down to room temperature).

At the very least, double-check the RAM specs to see what it's designed
to be clocked at, and make sure the BIOS reports that the RAM is
clocked at a specified compatible setting.

-- 
Michael Kjörling                     🔗 https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”

Re: cryptsetup - No key available with passphrase

[Arno Wagner]

On Fri, Mar 03, 2023 at 08:55:50 CET, Milan Broz wrote:
> But memory failure is just a recipe for disaster later...)

I agree. I usually run memtest86+ (there is a new version out)
for 2 days, just to be sure. Things have gotten better with
DDR5 (on-chip ECC), but you can still get failures in buses
or uncorrectable errors with low-quality RAM. Sometimes the
RAM is even completely fine, but the mainboard manufacturer
has screwed up the parameters that the BIOS uses. 

Regards,
Arno
-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier

Re: cryptsetup - No key available with passphrase

[Lars Francke]

On Fri, Mar 3, 2023 at 6:43 PM Arno Wagner <arno@wagner.name> wrote:
>
> On Fri, Mar 03, 2023 at 08:55:50 CET, Milan Broz wrote:
> > But memory failure is just a recipe for disaster later...)
>
> I agree. I usually run memtest86+ (there is a new version out)
> for 2 days, just to be sure. Things have gotten better with
> DDR5 (on-chip ECC), but you can still get failures in buses
> or uncorrectable errors with low-quality RAM. Sometimes the
> RAM is even completely fine, but the mainboard manufacturer
> has screwed up the parameters that the BIOS uses.

This is what looks like happened here.
BIOS update seems to have screwed up the parameters,
Once I reset those everything worked again.

Maybe what cryptsetup could do is an addition to the FAQ that
intermittent/spurious/weird mistakes warrant a memory check.

Cheers,
Lars


>
> Regards,
> Arno
> --
> Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
> GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
> ----
> A good decision is based on knowledge and not on numbers. -- Plato
>
> If it's in the news, don't worry about it.  The very definition of
> "news" is "something that hardly ever happens." -- Bruce Schneier