LUKS-Passphrase not working after update

bk · 2014-01-15 08:19:59

Hi,

after a long time I updated one of my laptop yesterday (last update was on 2013-12-29).
After a pacman -Syu my problem is that cryptsetup seems not to accept my correct password for my encrypted /.

The order of hooks in mkinitcpio.conf is the same as before the update.

For debugging I modified my initramfs by adding launch_interactive_shell one line before the call of cryptsetup into the encrypt-hook-file. Keyboardlayout was correct, dm_crypt and dm_mod loaded.
Using strace in initramfs I've seen that my entered passphrase was the correct one, but cryptsetup says that my correct one isn't the correct one (No key available with this passphrase)

Using a livecd my passphrase works (same keyboardlayout / identical phrase) ...

Here the pacman.log of my last update

Any idea?

EDIT:

Even after adding a new passphrase to a different keyslot cryptsetup will not accept this new one...

Last edited by bk (2014-01-15 09:45:17)

poplin · 2014-01-15 21:37:56

Hi bk,

Same problem here. Downgrading to cryptsetup-1.6.3-1-x86_64.pkg.tar.xz libgcrypt-1.5.3-1-x86_64.pkg.tar.xz allowed me to decrypt.

Once downgraded, after reboot I was not able to mount any crypt partition (the system hangs or maybe take ages, as reported by Fruckiwacki ).

So my workaround so far involves manually mounting the partitions... :-(

bk · 2014-01-15 22:07:19

poplin wrote:

Downgrading to cryptsetup-1.6.3-1-x86_64.pkg.tar.xz libgcrypt-1.5.3-1-x86_64.pkg.tar.xz allowed me to decrypt.

Tested it, too. Here my result:
libgcrypt-1.6.0-1 + cryptsetup-1.6.3-2 = no decrypt
libgcrypt-1.5.3 + cryptsetup-1.6.2-2 = decrypt (without mount)

So what would be the next step to get this fixed?

jynnantonix · 2014-01-15 22:48:56

I'm having the exact same issue, although I use a keyfile on a usb stick. I can confirm that downgrading to libgcrypt-1.5.3 + cryptsetup1.6.3-1 allows me to decrypt my rootfs but libgcrypt-1.6.0 + cryptsetup1.6.3-2 gives me a "No keyslot matches this passphrase" message followed by an "Invalid keyfile" error.

jjacky · 2014-01-15 23:32:06

Did you try either with cryptsetup using its own pbkdf2 implementation, or with the patch for libgcrypt (both mentioned here), to see if it changes anything?

jynnantonix · 2014-01-16 00:44:17

I built cryptsetup with the configure patch from here after fixing the yes -> xyes typo. If I understand correctly this defaults to using the internal pbkdf2 implementation so the only change I made to the PKGBUILD from [core] was to apply the patch in a prepare function. After building and installing the new cryptsetup, I rebuilt the initramfs before rebooting. Unfortunately, this didn't seem to make a difference as I got the same error about the invalid keyfile.

jjacky · 2014-01-16 08:38:58

Actually you also need to add --disable-gcrypt-pbkdf2 to the configure line in the PKGBUILD, otherwise (with libgcrypt 1.6.0) it defaults to using libgcrypt's implementation. The patch allows the --disable-gcrypt-pbkdf2 option to work (without it you can only force to enable it, not disable it)

plasmoid · 2014-01-16 10:37:08

jjacky wrote:

Actually you also need to add --disable-gcrypt-pbkdf2 to the configure line in the PKGBUILD, otherwise (with libgcrypt 1.6.0) it defaults to using libgcrypt's implementation. The patch allows the --disable-gcrypt-pbkdf2 option to work (without it you can only force to enable it, not disable it)

bk/jynnantonix can you confirm that the patch and --disable-gcrypt-pbkdf2 fixes the problem?

jynnantonix · 2014-01-16 18:46:14

plasmoid wrote:

bk/jynnantonix can you confirm that the patch and --disable-gcrypt-pbkdf2 fixes the problem?

I rebuilt it with --disable-gcrypt-pbkdf2 but sadly I still get the "No key available for this passphrase" error. I think this is a problem with libgcrypt rather than cryptsetup:

- libgcrypt-1.5.3 + cryptsetup-1.6.3-1 works
- libgcrypt-1.6.0 + cryptsetup-1.6.3-2 does not work
- Since cryptsetup only got a package version bump I would hope that the source code itself did not change. It was only repackaged because libgcrypt got a major version bump

What else can I try to troubleshoot this problem? I'm not very familiar with cryptsetup or libgcrypt so I'm not really sure where to start

bk · 2014-01-16 18:55:56

jynnantonix wrote:

plasmoid wrote:
bk/jynnantonix can you confirm that the patch and --disable-gcrypt-pbkdf2 fixes the problem?
I rebuilt it with --disable-gcrypt-pbkdf2 but sadly I still get the "No key available for this passphrase" error.

Have done the same right before jynnantonix was posting: Can confirm, still broken.

clfarron4 · 2014-01-16 19:10:44

I recently re-built my system (on Tuesday, not because of LVM on LUKS) and I have that:

cryptsetup-nuke-keys (AUR) 1.6.3-2 + libgcrypt 1.6.0-1 = works
cryptsetup 1.6.3-2 + libgcrypt 1.6.0-1 = works

eisensheng · 2014-01-16 19:25:39

I'm also affected by this. I can't open an older LUKS container with
libgcrypt-1.6.0 + cryptsetup-1.6.3-2
but with
libgcrypt-1.5.3 + cryptsetup-1.6.3-1
it works.

On the other hand I can open a newly created LUKS container with the same hash algo, the same cipher and the same key size with
libgcrypt-1.6.0 + cryptsetup-1.6.3-2

jjacky · 2014-01-16 21:05:35

No idea what could be causing this, but it sounds like an issue that should be reported to cryptsetup.

clfarron4 · 2014-01-16 21:34:16

eisensheng wrote:

I'm also affected by this. I can't open an older LUKS container with
libgcrypt-1.6.0 + cryptsetup-1.6.3-2
but with
libgcrypt-1.5.3 + cryptsetup-1.6.3-1
it works.
On the other hand I can open a newly created LUKS container with the same hash algo, the same cipher and the same key size with
libgcrypt-1.6.0 + cryptsetup-1.6.3-2

So it reads like this issue is only affecting older LUKS containers.

eisensheng · 2014-01-16 22:14:42

Appears to be a problem with the whirlpool hash option.

I've created the following LUKS containers on an older system with

libgcrypt 1.5.3-1
cryptsetup 1.6.3-1

and tried to open those LUKS containers on an updated system with

libgcrypt 1.6.0-1
cryptsetup 1.6.3-2

# cryptsetup luksFormat /dev/sdj1 --hash whirlpool -c aes-cbc-plain -s 128

can't open

# cryptsetup luksFormat /dev/sdj1 --hash whirlpool -c serpent-xts-essiv:sha256 -s 128

can't open

# cryptsetup luksFormat /dev/sdj1 --hash sha1 -c serpent-xts-essiv:sha256 -s 128

can open

I would be glad if someone else could contact upstream about this. I'm heading to bed for now.

Last edited by eisensheng (2014-01-16 22:15:35)

clfarron4 · 2014-01-17 10:13:46

I've opened a bug report on the Arch Bug Tracker here: https://bugs.archlinux.org/task/38550

Please comment there on your findings.

bk · 2014-01-17 14:03:51

eisensheng wrote:

Appears to be a problem with the whirlpool hash option.

I think this is very plausible. Between 1.5.3 and 1.6.0 there was a huge amount of changes in whirlpool.c.

Spider.007 · 2014-01-17 17:42:26

clfarron4 wrote:

I've opened a bug report on the Arch Bug Tracker here: https://bugs.archlinux.org/task/38550
Please comment there on your findings.

No offense, but why not go upstream directly? The arch-dev's cannot fix this and will be more likely to pass a new update with higher priority (rather then rolling back)

Last edited by Spider.007 (2014-01-17 17:43:32)

clfarron4 · 2014-01-17 18:24:47

Spider.007 wrote:

clfarron4 wrote:
I've opened a bug report on the Arch Bug Tracker here: https://bugs.archlinux.org/task/38550
Please comment there on your findings.
No offense, but why not go upstream directly? The arch-dev's cannot fix this and will be more likely to pass a new update with higher priority (rather then rolling back)

I don't actually have this problem, which I tested on my other rig, so I have no motivation to report upstream to the cryptsetup.

eisensheng · 2014-01-17 19:57:53

I got the 200 for this issue: <https://code.google.com/p/cryptsetup/issues/detail?id=200>. Lets wait and see.

plasmoid · 2014-01-17 21:00:39

I also haven't experienced this issue using aes-xts-plain:

# cryptsetup luksDump /dev/sda2
...
Cipher name:    aes
Cipher mode:    xts-plain
Hash spec:      sha1
Payload offset: 4040
MK bits:        512
...

SidK · 2014-01-18 10:24:17

I had an odd experience, which might be a coincidence. I have two partitions using luks, both with default settings:

Version:       	1
Cipher name:   	aes
Cipher mode:   	xts-plain64
Hash spec:     	sha1
Payload offset:	4096
MK bits:       	256

This morning as I booted both my encrypted partitions failed to be decrypted. I found this thread on my phone, so I thought perhaps I should downgrade the cryptsetup package. My terminal was stuck doing a manual cryptsetup luksOpen, so I held the power button and rebooted that way. On the second boot everything worked fine. No problems.

So perhaps it was just a coincidence, but this hasn't happened to me before. I guess if others have the same thing happen, then it's worth looking into. Sorry I didn't get more info out on the failed boot.

bk · 2014-01-18 19:36:11

My current workaround was this:
- cryptsetup-reencrypt -h sha1 /dev/sdaX
- upgrade to libgcrypt 1.6.0
- cryptsetup-reencrypt -h whirlpool /dev/sdaX

I skipped my last point to save time a reencrypt-run takes.

Remember: cryptsetup-reencrypt is experimental!

brain0 · 2014-01-19 09:48:06

This thread is highly relevant: http://www.saout.de/pipermail/dm-crypt/ … 03813.html

It turns out the implementation of whirlpool was incorrect in all older cryptsetup versions! There may be some solution later to allow opening the old volumes with new libgcrypt. However, I still advise everyone who is affected to back up their data, re-create their LUKS volume and restore the backup.

bk · 2014-01-20 22:08:58

Bug emulation flag added
http://git.gnupg.org/cgi-bin/gitweb.cgi … d51a531b72

Will be backported
http://www.saout.de/pipermail/dm-crypt/ … 03823.html

Arch Linux

#1 2014-01-15 08:19:59

LUKS-Passphrase not working after update

#2 2014-01-15 21:37:56

Re: LUKS-Passphrase not working after update

#3 2014-01-15 22:07:19

Re: LUKS-Passphrase not working after update

#4 2014-01-15 22:48:56

Re: LUKS-Passphrase not working after update

#5 2014-01-15 23:32:06

Re: LUKS-Passphrase not working after update

#6 2014-01-16 00:44:17

Re: LUKS-Passphrase not working after update

#7 2014-01-16 08:38:58

Re: LUKS-Passphrase not working after update

#8 2014-01-16 10:37:08

Re: LUKS-Passphrase not working after update

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

Re: LUKS-Passphrase not working after update

#10 2014-01-16 18:55:56

Re: LUKS-Passphrase not working after update

#11 2014-01-16 19:10:44

Re: LUKS-Passphrase not working after update

#12 2014-01-16 19:25:39

Re: LUKS-Passphrase not working after update

#13 2014-01-16 21:05:35

Re: LUKS-Passphrase not working after update

#14 2014-01-16 21:34:16

Re: LUKS-Passphrase not working after update

#15 2014-01-16 22:14:42

Re: LUKS-Passphrase not working after update

#16 2014-01-17 10:13:46

Re: LUKS-Passphrase not working after update

#17 2014-01-17 14:03:51

Re: LUKS-Passphrase not working after update

#18 2014-01-17 17:42:26

Re: LUKS-Passphrase not working after update

#19 2014-01-17 18:24:47

Re: LUKS-Passphrase not working after update

#20 2014-01-17 19:57:53

Re: LUKS-Passphrase not working after update

#21 2014-01-17 21:00:39

Re: LUKS-Passphrase not working after update

#22 2014-01-18 10:24:17

Re: LUKS-Passphrase not working after update

#23 2014-01-18 19:36:11

Re: LUKS-Passphrase not working after update

#24 2014-01-19 09:48:06

Re: LUKS-Passphrase not working after update

#25 2014-01-20 22:08:58

Re: LUKS-Passphrase not working after update

Board footer