FS#74786 - [cryptsetup] can't open new luks2 volume

Attached to Project: Arch Linux
Opened by Radomir Palovsky (r.palovsky) - Wednesday, 18 May 2022, 15:18 GMT
Last edited by Toolybird (Toolybird) - Thursday, 28 July 2022, 05:04 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To No-one
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
In new installation 2022.05.01 is not possible perform wiki "dm-crypt/Encrypting an entire system"

commands (from wiki)

# cryptsetup -y -v luksFormat /dev/sda2
# cryptsetup open /dev/sda2 root

don't open encrypted volume. (with right passwords)

Investigation with --debug switch in both commands reveals, that the problem is in pbkdf configuration.
In luks2 type "luksFormat" works with argon2id pbkdf while open works with pbkdf2 pbkdf and verification failed.
In luks1 type both (format and open) works with pbkdf2 and volume is opened.

Workaround for luks2 type is explicitly specified

# cryptsetup -y -v --pbkdf pbkdf2 luksFormat /dev/sda2

but it isn't quite right.




Additional info:
* package version(s)
* config and/or log files etc.
* link to upstream bug report, if any

Steps to reproduce:

# cryptsetup -y -v luksFormat /dev/sda2
# cryptsetup open /dev/sda2 root
This task depends upon

Closed by  Toolybird (Toolybird)
Thursday, 28 July 2022, 05:04 GMT
Reason for closing:  Works for me
Comment by cmm11 (cmm11) - Sunday, 22 May 2022, 18:32 GMT
I've quickly checked to see if i can reproduce in a VM.
Booted (archlinux-2022.05.01-x86_64.iso) in a VM (QEMU + virt-manager)
Steps i did:
cfdisk /dev/vda
# Created a 500MB /dev/vda1 partition & the rest of the 20GB virtual drive as /dev/vda2
cryptsetup -y -v luksFormat /dev/vda2
# I get output: Key slot 0 Created, Command successful.
cryptsetup open /dev/vda2 root
# Enter passphrase and no errors are displayed.
Comment by Toolybird (Toolybird) - Thursday, 28 July 2022, 05:04 GMT
Not sure what is/was going wrong for the reporter, but like @cmm11, I cannot reproduce this.

Loading...