View previous topic :: View next topic |
Author |
Message |
Zoosannn n00b
Joined: 24 Jun 2024 Posts: 5
|
Posted: Tue Jul 23, 2024 3:03 am Post subject: [SOLVED] "Wrong password" on LUKS boot |
|
|
Hi all,
After boot, when attempting to unlock my LUKS encrypted root, I am met with:
Code: |
Keyslot open failed.
Wrong password
|
I am confident that it is the valid password, considering I am capable of unlocking the partition in a liveCD with no issues.
I'm wondering if it could be that I don't have either the right LUKS options or the right cryptographic keys built into the kernel, so it can't use the password.
My kernel config:
https://dpaste.com/HB5J6KGLH
The output of Code: | cryptsetup luksDump /dev/nvme0n1p2 |
https://dpaste.com/8EUEF7NVQ
My dracut config:
Code: | /etc/dracut.conf.d/luks.conf
add_dracutmodules+=" crypt btrfs "
|
My GRUB config:
Code: | /etc/default/grub
GRUB_DISABLE_LINUX_PARTUUID=false
GRUB_DISTRIBUTOR="Gentoo"
GRUB_TIMEOUT=3
GRUB_ENABLE_CRYPTODISK=y
GRUB_CMDLINE_LINUX_DEFAULT="root=UUID=9b4a31aa-e384-48c8-a884-af30333050e3 rd.luks.uuid=c1df8295-552e-4b71-a4af-a08e8f4383b8 rd.luks.allow-discards quiet"
|
My /etc/fstab:
Code: |
# <fs> <mountpoint> <type> <opts> <dump> <pass>
LABEL=ROOTFS / btrfs defaults,noatime,compress=lzo,autodefrag,discard=async,subvol=activeroot 0 0
LABEL=ROOTFS /home btrfs defaults,noatime,compress=lzo,autodefrag,discard=async,subvol=home 0 0
UUID=3D3D-4C73 /boot vfat umask=077 0 1
UUID=3D3D-4C73 /efi vfat umask=077 0 1
|
Any help would be appreciated, thanks.
EDIT:
Forgot to add the output of lsblk -o name,uuid
Code: |
NAME UUID
loop0
sda 2024-07-14-19-57-44-00
├─sda1
├─sda2 49D2-A1AF
├─sda3
└─sda4
nvme0n1
├─nvme0n1p1 3D3D-4C73
└─nvme0n1p2 c1df8295-552e-4b71-a4af-a08e8f4383b8
└─root 9b4a31aa-e384-48c8-a884-af30333050e3
|
Last edited by Zoosannn on Mon Aug 05, 2024 4:31 pm; edited 1 time in total |
|
Back to top |
|
|
sdauth l33t
Joined: 19 Sep 2018 Posts: 645 Location: Ásgarðr
|
Posted: Tue Jul 23, 2024 12:02 pm Post subject: |
|
|
I might be wrong but
is (still) not supported for / by grub unless patches are used. (https://leo3418.github.io/collections/gentoo-config-luks2-grub-systemd/packages.html for example)
Since you can open it from a livecd, this is probably the issue here.
When you use cryptsetup luksFormat, it defaults to argon2i (or argon2id) unless --pbkdf args is used.
Code: | ~ cryptsetup -?
Default compiled-in key and passphrase parameters:
Maximum keyfile size: 8192kB, Maximum interactive passphrase length 512 (characters)
Default PBKDF for LUKS1: pbkdf2, iteration time: 2000 (ms)
Default PBKDF for LUKS2: argon2id
Iteration time: 2000, Memory required: 1048576kB, Parallel threads: 4
Default compiled-in device cipher parameters:
loop-AES: aes, Key 256 bits
plain: aes-xts-plain64, Key: 256 bits, Password hashing: sha256
LUKS: aes-xts-plain64, Key: 256 bits, LUKS header hashing: sha256, RNG: /dev/urandom
LUKS: Default keysize with XTS mode (two internal keys) will be doubled. |
from my notes:
Code: | # if drive is used for /; use "--pbkdf pbkdf2" instead of argon2i/argon2id
cryptsetup luksFormat --cipher serpent-xts-plain64 --key-size 512 --hash sha512 --pbkdf pbkdf2 --iter-time 5000 --use-random /dev/sda1 |
You could try to change the key from argon2id to pbkdf2 ; make sure to backup headers before or have backup at hand.
Code: | cryptsetup luksChangeKey /dev/nvme0n1p2 -S 2 --hash sha256 --pbkdf pbkdf2 --iter-time 5000 |
(re enter your passphrase, this command is used to change pbkdf)
Since your current key is in slot 2, I added "-S 2" to select the slot.
Otherwise you could also use luksAddKey instead, select slot 1 for example (-S 1) and add a whole new passphrase.
Code: | cryptsetup luksAddKey /dev/nvme0n1p2 -S 1 --hash sha256 --pbkdf pbkdf2 --iter-time 5000 |
If you don't want to modify anything, maybe just try the argon2id support patch for grub first |
|
Back to top |
|
|
Hu Administrator
Joined: 06 Mar 2007 Posts: 22619
|
Posted: Tue Jul 23, 2024 12:27 pm Post subject: |
|
|
Another possibility that affects some people is the use of a password containing characters outside basic ANSI. Entering such a password requires that the loaded keyboard layout now match what was loaded when the volume was first formatted. For some users who prefer a non-English language as their primary language, and who load a keyboard layout accordingly, they may have created the password with a different encoding than is used in the initramfs. |
|
Back to top |
|
|
Zoosannn n00b
Joined: 24 Jun 2024 Posts: 5
|
Posted: Tue Jul 23, 2024 12:48 pm Post subject: |
|
|
sdauth wrote: | I might be wrong but
is (still) not supported for / by grub unless patches are used. (https://leo3418.github.io/collections/gentoo-config-luks2-grub-systemd/packages.html for example)
Since you can open it from a livecd, this is probably the issue here.
When you use cryptsetup luksFormat, it defaults to argon2i (or argon2id) unless --pbkdf args is used.
Code: | ~ cryptsetup -?
Default compiled-in key and passphrase parameters:
Maximum keyfile size: 8192kB, Maximum interactive passphrase length 512 (characters)
Default PBKDF for LUKS1: pbkdf2, iteration time: 2000 (ms)
Default PBKDF for LUKS2: argon2id
Iteration time: 2000, Memory required: 1048576kB, Parallel threads: 4
Default compiled-in device cipher parameters:
loop-AES: aes, Key 256 bits
plain: aes-xts-plain64, Key: 256 bits, Password hashing: sha256
LUKS: aes-xts-plain64, Key: 256 bits, LUKS header hashing: sha256, RNG: /dev/urandom
LUKS: Default keysize with XTS mode (two internal keys) will be doubled. |
from my notes:
Code: | # if drive is used for /; use "--pbkdf pbkdf2" instead of argon2i/argon2id
cryptsetup luksFormat --cipher serpent-xts-plain64 --key-size 512 --hash sha512 --pbkdf pbkdf2 --iter-time 5000 --use-random /dev/sda1 |
You could try to change the key from argon2id to pbkdf2 ; make sure to backup headers before or have backup at hand.
Code: | cryptsetup luksChangeKey /dev/nvme0n1p2 -S 2 --hash sha256 --pbkdf pbkdf2 --iter-time 5000 |
(re enter your passphrase, this command is used to change pbkdf)
Since your current key is in slot 2, I added "-S 2" to select the slot.
Otherwise you could also use luksAddKey instead, select slot 1 for example (-S 1) and add a whole new passphrase.
Code: | cryptsetup luksAddKey /dev/nvme0n1p2 -S 1 --hash sha256 --pbkdf pbkdf2 --iter-time 5000 |
If you don't want to modify anything, maybe just try the argon2id support patch for grub first |
Unfortunately, while the patch for grub didn't seem to work, switching my key to pbkdf seems to have done the trick. Thanks for your help!
Quote: |
Another possibility that affects some people is the use of a password containing characters outside basic ANSI. Entering such a password requires that the loaded keyboard layout now match what was loaded when the volume was first formatted. For some users who prefer a non-English language as their primary language, and who load a keyboard layout accordingly, they may have created the password with a different encoding than is used in the initramfs.
|
I had considered that, but considering I use basic ANSI symbols and the default US keymap, I didn't think it was the issue. |
|
Back to top |
|
|
sdauth l33t
Joined: 19 Sep 2018 Posts: 645 Location: Ásgarðr
|
Posted: Thu Jul 25, 2024 3:35 pm Post subject: |
|
|
Zoosannn wrote: | Unfortunately, while the patch for grub didn't seem to work, switching my key to pbkdf seems to have done the trick. Thanks for your help! |
You're welcome.
About the patch, I have not tested the argon2i patch myself so maybe it doesn't work at all.
But just an idea, have you reinstalled grub to your nvme drive (nvme0n1p1) after the rebuild with the patch ? (grub-install --recheck --no-floppy (if using bios booting) )
edit: For fun, I replicated your setup with one of my gentoo vm, with argon2id for pbkdf & dracut. (with some difference like dos/mbr used)
I was expecting the same error message but it booted just fine. Without patch.
I guess the patch is needed when one is using full disk encryption (including /boot) but that was not your case so it should have worked with argon2id. Strange, I'm a bit confused now
Code: | ~ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 80G 0 disk
├─sda1 8:1 0 500M 0 part /boot
└─sda2 8:2 0 79,5G 0 part
└─luks-07f6af99-7dea-4e3f-b408-9986016f8ea1 253:0 0 79,5G 0 crypt /
|
Code: | ~ cryptsetup luksDump /dev/sda2
LUKS header information
Version: 2
Epoch: 5
Metadata area: 16384 [bytes]
Keyslots area: 16744448 [bytes]
UUID: 07f6af99-7dea-4e3f-b408-9986016f8ea1
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: 14
Memory: 1048576
Threads: 4
Salt: f5 f5 44 50 84 62 a5 f5 08 c9 e6 2b c6 6d da 80
88 3d ec 20 80 c2 b1 ef 6a 87 c3 65 9e 40 1b be
AF stripes: 4000
AF hash: sha512
Area offset:290816 [bytes]
Area length:258048 [bytes]
Digest ID: 0
Tokens:
Digests:
0: pbkdf2
Hash: sha512
Iterations: 126273
Salt: 18 bc 3e 9c 19 01 47 eb 41 50 26 9c 32 49 1d de
6c 25 8c 77 d7 3c b1 36 7e 74 34 fd 19 f2 a0 bf
Digest: b2 e4 77 6b ea 00 56 e5 3f f4 fd 98 1b af 8d 56
39 58 de 06 3d 66 12 be 44 98 af cb 1e 8d 6e e4
62 61 d7 35 72 3a b0 ed 81 8c 40 81 56 79 a6 59
b4 52 81 79 00 f6 de 1d 58 8a 7b ab e2 df 49 c5
|
|
|
Back to top |
|
|
Zoosannn n00b
Joined: 24 Jun 2024 Posts: 5
|
Posted: Mon Aug 05, 2024 4:38 pm Post subject: |
|
|
sdauth wrote: |
edit: For fun, I replicated your setup with one of my gentoo vm, with argon2id for pbkdf & dracut. (with some difference like dos/mbr used)
I was expecting the same error message but it booted just fine. Without patch.
I guess the patch is needed when one is using full disk encryption (including /boot) but that was not your case so it should have worked with argon2id. Strange, I'm a bit confused now
|
Strange, I have no clue what I did to that particular install (I've reinstalled as I wanted to experiment with musl/LLVM) I've done essentially the same thing, at least in terms of rootfs encryption with this new install, and no issues.
sdauth wrote: |
But just an idea, have you reinstalled grub to your nvme drive (nvme0n1p1) after the rebuild with the patch ? (grub-install --recheck --no-floppy (if using bios booting) )
|
I had reinstalled grub but, as you know, it hadn't resolved the issue. Oh well, another "unsolved" mystery. Hopefully my post helps another lost soul |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|