encrypt hook wont find keyfile after upgrading cryptsetup/libgcrypt?!

Fruckiwacki · 2014-01-14 16:45:14

Hello,

after yesterdays upgrades (kernel, libgcrypt, cryptsetup) I cannot unlock my rootfs by keyfile anymore.

Screenshot 1: https://www.dropbox.com/s/dhdskjdd1eaq6 … 7%2058.jpg

This is where it normally unlocked the rootfs but it wont happen anymore. Its stuck there forever.

Screenshot 2: https://www.dropbox.com/s/gcnpva9x50pyy … 9%2012.jpg

Removing the sd-card thats holding the keyfile I can successfully decrypt my rootfs by entering a passphrase.

Downgrading cryptsetup and libgcrypt solves the problems but the system then takes like 10 minutes to boot (mostly hanging on 'Created slice Root Slice.').

Help would be much appreciated.

Edit:

syslinux.cfg:

APPEND root=/dev/arch/root cryptdevice=/dev/sda2:cryptroot cryptkey=/dev/disk/by-uuid/9526e210-9c4e-4875-9f28-353d34873574:ext2:/KEYFILE rw

mkinitcpio.conf:

MODULES="rts5139 libata sd_mod scsi_mod ext2 usbhid"
HOOKS="base udev autodetect modconf keyboard block encrypt lvm2 filesystems shutdown fsck"

Last edited by Fruckiwacki (2014-01-15 03:36:41)

Scimmia · 2014-01-14 16:46:15

Did you rebuild your initramfs with the new libgcrypt installed?

Last edited by Scimmia (2014-01-14 16:47:10)

Fruckiwacki · 2014-01-14 16:51:57

Yeah, build without any errors/warnings.

jjacky · 2014-01-15 16:18:28

Are you sure it's really stuck forever? Maybe just very very slow...

I've experienced something similar with the recent updates as well, when luksOpenning a device with a keyfile, instead of being pretty much instant it took long minutes. Testing in a VM a simple --test-passphrase went from a few seconds to over 5 minutes!

From what I've gathered, cryptsetup used its own pbkdf2 implementation as there was a bug in libgcrypt. This bug fixed in libgcrypt 1.6.0 it's now (back to?) using libgcrypt's; Only it's obviously *much* slower. Unfortunately there's no configure option to force disabling the use of libgcrypt's implementation (only force enable it). As a workaround I've patched the configure.ac & recompiled cryptsetup with --disable-gcrypt-pbkdf2 and now things are back to normal.

jjacky · 2014-01-15 18:46:51

Follow up: https://bugs.archlinux.org/task/38533

Issue was reported on cryptsetup, and it is a bug in libgcrypt for which a patch has already been accepted upstream; So there is even a proper fix.

Dunkelschorsch · 2014-01-16 09:40:54

Hello,
I got a similar problem with my setup: the updated cryptsetup/libgcrypt doesn't accept the correct passphrase. --test-passphrase instantly tells me: there is no key with the supplied passphrase. Downgrading cryptsetup and libgcrypt brings everything back to normal. Is this also related to the above mentioned bug?

jjacky · 2014-01-16 11:10:16

Doesn't sound like it, if you get an error right away. I could always decrypt my devices, it only took quite a long time.

However, since the only recent change was the upgrade of libgcrypt, it might be good for you to test using the patch & --disable-gcrypt-pbkdf2 to see if it's linked or not - in case there's some bug in libgcrypt's pbkdf2 implementation. If it works then, it might be that there's another bug to report against libgcrypt; if not, try adding --debug to see where things fail.

krachyon · 2014-01-16 13:49:03

I'm also experiencing what seems to be Dunkelschorsch's problem: After a full system upgrade the passphrase is rejected.
After downgrading the kernel, libgcrypt and cryptsetup to a snapshot from the arch rollback machine (http://seblu.net/a/arm/2013/12/24/) the passphrase is accepted again, but the fsck hook runs into a timeout after about 10 minutes.

Yet I'm pretty certain I did a system update around christmas and ran these package versions with no passphrase or timeout issues. Does this make any sense?

I'm currently trying out jjacky's patch and will report if that fixes the issue...

Luks-Information:
Version:    1
Cipher name:    twofish
Cipher mode:    xts-essiv:sha256
Hash spec:    whirlpool
Payload offset: 4096
MK bits:    256

Edit: Passphrase is again rejected with the patch. @Dunkelschorsch: Which versions of the kernel, libgcrypt and cryptsetup did you downgrade to?

Last edited by krachyon (2014-01-16 14:38:59)

Dunkelschorsch · 2014-01-16 14:46:19

I also just tried with all combinations of patched libgcrypt/--disable-gcrypt-pbkdf2. Conclusion: it just refuses to work with libgcrypt-1.6.

Here is the --debug output of the failed attempt:

# cryptsetup 1.6.3 processing "cryptsetup luksOpen /dev/sda3 --test-passphrase --debug"
# Running command open.
# Locking memory.
# Installing SIGINT/SIGTERM handler.
# Unblocking interruption on signal.
# Allocating crypt device /dev/sda3 context.
# Trying to open and read device /dev/sda3.
# Initialising device-mapper backend library.
# Trying to load LUKS1 crypt type from device /dev/sda3.
# Crypto backend (gcrypt 1.6.0) initialized.
# Reading LUKS header of size 1024 from device /dev/sda3
# Key length 32, device size 488259919 sectors, header size 2050 sectors.
# Timeout set to 0 miliseconds.
# Password retry count set to 3.
# Password verification disabled.
# Iteration time set to 1000 miliseconds.
# Checking volume  [keyslot -1] using [none] passphrase.
# Interactive passphrase entry requested.
Geben Sie die Passphrase für /dev/sda3 ein: 
# Trying to open key slot 0 [ACTIVE_LAST].
# Reading key slot 0 area.
# Calculated device size is 250 sectors (RW), offset 8.
# Detected kernel Linux 3.12.7-1-ARCH x86_64.
# dm version   OF   [16384] (*1)
# dm versions   OF   [16384] (*1)
# Detected dm-crypt version 1.12.1, dm-ioctl version 4.26.0.
# Device-mapper backend running with UDEV support enabled.
# DM-UUID is CRYPT-TEMP-temporary-cryptsetup-4732
# Udev cookie 0xd4df547 (semid 458752) created
# Udev cookie 0xd4df547 (semid 458752) incremented to 1
# Udev cookie 0xd4df547 (semid 458752) incremented to 2
# Udev cookie 0xd4df547 (semid 458752) assigned to CREATE task(0) with flags DISABLE_SUBSYSTEM_RULES DISABLE_DISK_RULES DISABLE_OTHER_RULES (0xe)
# dm create temporary-cryptsetup-4732 CRYPT-TEMP-temporary-cryptsetup-4732 OF   [16384] (*1)
# dm reload temporary-cryptsetup-4732  OFRW    [16384] (*1)
# dm resume temporary-cryptsetup-4732  OFRW    [16384] (*1)
# temporary-cryptsetup-4732: Stacking NODE_ADD (254,4) 0:0 0600 [verify_udev]
# temporary-cryptsetup-4732: Stacking NODE_READ_AHEAD 256 (flags=1)
# Udev cookie 0xd4df547 (semid 458752) decremented to 1
# Udev cookie 0xd4df547 (semid 458752) waiting for zero
# Udev cookie 0xd4df547 (semid 458752) destroyed
# temporary-cryptsetup-4732: Processing NODE_ADD (254,4) 0:0 0600 [verify_udev]
# temporary-cryptsetup-4732: Processing NODE_READ_AHEAD 256 (flags=1)
# temporary-cryptsetup-4732 (254:4): read ahead is 256
# temporary-cryptsetup-4732: retaining kernel read ahead of 256 (requested 256)
# Udev cookie 0xd4ddb3d (semid 491520) created
# Udev cookie 0xd4ddb3d (semid 491520) incremented to 1
# Udev cookie 0xd4ddb3d (semid 491520) incremented to 2
# Udev cookie 0xd4ddb3d (semid 491520) assigned to REMOVE task(2) with flags (0x0)
# dm remove temporary-cryptsetup-4732  OFT    [16384] (*1)
# temporary-cryptsetup-4732: Stacking NODE_DEL [verify_udev]
# Udev cookie 0xd4ddb3d (semid 491520) decremented to 1
# Udev cookie 0xd4ddb3d (semid 491520) waiting for zero
# Udev cookie 0xd4ddb3d (semid 491520) destroyed
# temporary-cryptsetup-4732: Processing NODE_DEL [verify_udev]
# Trying to open key slot 1 [INACTIVE].
# Trying to open key slot 2 [INACTIVE].
# Trying to open key slot 3 [INACTIVE].
# Trying to open key slot 4 [INACTIVE].
# Trying to open key slot 5 [INACTIVE].
# Trying to open key slot 6 [INACTIVE].
# Trying to open key slot 7 [INACTIVE].
Kein Schlüssel mit dieser Passphrase verfügbar.
# Interactive passphrase entry requested.
Geben Sie die Passphrase für /dev/sda3 ein: Fehler beim Lesen der Passphrase vom Terminal.
# Releasing crypt device /dev/sda3 context.
# Releasing device-mapper backend.
# Unlocking memory.
Befehl fehlgeschlagen mit Code 22: Fehler beim Lesen der Passphrase vom Terminal.

@krachyon:
I'm on http://www.seblu.net/a/arm/2014/01/12/$repo/os/$arch currently.

edit: some more info
luks-information:
Version: 1
Cipher name: aes
Cipher mode: xts-benbi
Hash spec: whirlpool
Payload offset: 2056
MK bits: 256

Last edited by Dunkelschorsch (2014-01-16 14:49:08)

krachyon · 2014-01-16 17:49:54

Update from me: After reverting only the kernel, kernel-headers, cryptsetup and libgcrypt to the snapshot from 2014/01/12 I was able to get past the pass phrase stage again, yet the system booted incredibly sluggish and after about 20 minutes the home target timed out. I tried reverting the rest of the packages to the snapshot as well but pacman refused as libgcrypt.20.so (or similar name) was apparently missing. I also somehow managed to create an initial ramdisk that was incompatible with grub.

Below the steps that worked in the end. Note that these where done after a full day of screwing around with the system and it's probably not very intelligent to reenact them:

(from rescue disk)
1) set mirror to http://www.seblu.net/a/arm/2014/01/12/$repo/os/$arch
2) Uninstall all packages that are newer than the ones from the repository
3) use pacstrap to reinstall those packages
4) execute mkinitcpio and grub-mkconfig

Now it's up and running again, but I guess I won't touch the packet manager for the next few days.

Sorry for the sloppy description. But maybe this gives someone that isn't on tilt/tired right now a clue as to what's going on...

Dunkelschorsch · 2014-01-21 07:47:50

a small update: it's still broken with the current version of libgcrypt (1.6.0-2).

krachyon · 2014-01-22 15:24:15

For those that have not yet seen the cause: https://bbs.archlinux.org/viewtopic.php?id=175737

Arch Linux

#1 2014-01-14 16:45:14

encrypt hook wont find keyfile after upgrading cryptsetup/libgcrypt?!

#2 2014-01-14 16:46:15

Re: encrypt hook wont find keyfile after upgrading cryptsetup/libgcrypt?!

#3 2014-01-14 16:51:57

Re: encrypt hook wont find keyfile after upgrading cryptsetup/libgcrypt?!

#4 2014-01-15 16:18:28

Re: encrypt hook wont find keyfile after upgrading cryptsetup/libgcrypt?!

#5 2014-01-15 18:46:51

Re: encrypt hook wont find keyfile after upgrading cryptsetup/libgcrypt?!

#6 2014-01-16 09:40:54

Re: encrypt hook wont find keyfile after upgrading cryptsetup/libgcrypt?!

#7 2014-01-16 11:10:16

Re: encrypt hook wont find keyfile after upgrading cryptsetup/libgcrypt?!

#8 2014-01-16 13:49:03

Re: encrypt hook wont find keyfile after upgrading cryptsetup/libgcrypt?!

#9 2014-01-16 14:46:19

Re: encrypt hook wont find keyfile after upgrading cryptsetup/libgcrypt?!

#10 2014-01-16 17:49:54

Re: encrypt hook wont find keyfile after upgrading cryptsetup/libgcrypt?!

#11 2014-01-21 07:47:50

Re: encrypt hook wont find keyfile after upgrading cryptsetup/libgcrypt?!

#12 2014-01-22 15:24:15

Re: encrypt hook wont find keyfile after upgrading cryptsetup/libgcrypt?!

Board footer