dd if=/dev/urandom of=secret.bin bs=1024 count=1
1+0 records in
1+0 records out
1024 bytes (1,0 kB, 1,0 KiB) copied, 9,1194e-05 s, 11,2 MB/s
create Fakedrive:
dd if=/dev/zero bs=1M count=2048 of=fakedrive.img
2048+0 records in
2048+0 records out
2147483648 bytes (2,1 GB, 2,0 GiB) copied, 16,2785 s, 132 MB/s
Format using the key:
cryptsetup luksFormat fakedrive.img secret.bin
WARNING!
========
This will overwrite data on fakedrive.img irrevocably.
Are you sure? (Type 'yes' in capital letters): YES
Open the encrypted fakedrive (all of these work)
one has --keyfile= and the other doesn’t have the “=”
sudo cryptsetup open --key-file secret.bin fakedrive.img test
sudo cryptsetup close test
sudo cryptsetup open --key-file=secret.bin fakedrive.img test
sudo cryptsetup close test
sudo cryptsetup luksOpen --key-file secret.bin fakedrive.img test
sudo cryptsetup close test
I hope you can successfully reproduce this.
You should be able to.
Key derivation works on files or passphrases. Makes no difference, other than one is stored as a file, while the other is memorized in the user’s brain. They are used to decrypt the Master Key, regardless if passphrase or keyfile, and they both use the same derivation function (PBKDF2, Argon2, etc.).
I just tried out the full ISO manjaro-gnome-21.3.7-220816-linux515.iso
It didn’t work.
I don’t think it’s worth you trying to reproduce this on your PC. I have an Asus Laptop running Manjaro, with a luks2 encrypted home, running just fine. I believe this is machine specific.
I can only make wild guesses: it can be a spurious error of the 5.15 / cryptsetup combo you use (but this should show up on another machine with the full ISO), it can be linked to the BIOS changes @frost19k made (due to failing kernel 6.0), or a failing component (e.g. one CPU core, see [2).
I think your best bet is to undo:
(reset to safe memory and default CPU settings, if you don’t remember your previous ones) and try to unlock your inaccessible blockdevices. If it works to unlock, make luks header backups first before adding any keys with anything other than argon. If it does not work, there should be a fair chance you can unlock the devices on another PC/notebook.
$ dd if=/dev/urandom of=secret.bin bs=1024 count=1
1+0 records in
1+0 records out
1024 bytes (1,0 kB, 1,0 KiB) copied, 0,000138671 s, 7,4 MB/s
$ dd if=/dev/zero bs=1M count=2048 of=fakedrive.img
2048+0 records in
2048+0 records out
2147483648 bytes (2,1 GB, 2,0 GiB) copied, 0,58842 s, 3,6 GB/s
$ cryptsetup luksFormat fakedrive.img secret.bin
WARNING!
========
This will overwrite data on fakedrive.img irrevocably.
Are you sure? (Type 'yes' in capital letters): YES
$ cryptsetup luksDump fakedrive.img
....
Keyslots:
0: luks2
Key: 512 bits
Priority: normal
Cipher: aes-xts-plain64
Cipher key: 512 bits
PBKDF: argon2id
Time cost: 12
Memory: 1048576
Threads: 4
Salt: 2c ad 13 c6 80 d9 29 57 b4 f4 d8 16 14 24 d3 1f
c4 2e 1c 45 20 1f 4b ba bc 18 cc 6d 42 c7 84 04
AF stripes: 4000
AF hash: sha256
Area offset:32768 [bytes]
Area length:258048 [bytes]
Digest ID: 0
....
$ sudo cryptsetup open --key-file secret.bin fakedrive.img test
$ ls /dev/mapper/
control test
$ sudo cryptsetup close test
$ ls /dev/mapper/
control
It works without any issue on my machine with DOCP.
I guess the issue is your RAM or mainboard that does not work with DOCP and argon2 together.
That’s good, it indeed looked like a weird software fluke. And yes, your verbosity in the original post was great, I missed that you had provided the luksDump there already.
I’m pretty sure the luks2 failure was just the first symptom and that you would have noticed other software crashes later. Consider that argon2 differs from pbkdf2 in two main points per design: 1. it uses much more memory and 2. multiple threads (up to 4 CPU; check your systems cryptsetup benchmark).
Both points are likely subject to your mainboards DOCP autotune (i.e. faster memory and CPU speeds). Now, if cryptsetup defaults to 2000ms iteration time, it means four threads will be fully loaded for two seconds with argon2 hashing, whereas pbkdf2 is single threaded (1/4 load and less memory per design). I can’t detail right away why the initial luks2 encryption with argon2 did not fail first, but the process itself to benchmark/encrypt/create the luks2 header is naturally different. To investigate one would have to observe system load differences for both tasks (luksFormat & open) and dive into respective code. So, if flaky DOCP is indeed the cause, you would have probably experienced crashes later in cpu intensive multithreaded tasks. These are my 2cents on it. Btw: perhaps your issues with the new kernel also vanish with these bios settings. Good luck.
edit:
Indeed, the combination of DOCP of the specific memory modules and/or cpu is what counts, not the autotune feature per se.
