LUKS passphrase not accepted any more.

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Create a LUKS container with whirlpool hashing enabled and libgcrypt 1.5.3 
and an associated passphrase.
2. Update to libgcrypt 1.6.0
3. Open previously created container

What is the expected output? What do you see instead?
Expected the given passphrase to be validated and the LUKS container to be 
opened.  No key for the given passphrase was found instead. 

What version of the product are you using? On what operating system?
libgcrypt-1.6.0-1
cryptsetup-1.6.3-2

Archlinux

Please provide any additional information below.
I did some further testing.  I've created a few images of 100MiByte in size and 
formatted them to LUKS containers with different cipher configuration 
alternating between sha1 and whirlpool on cryptsetup 1.6.0 and libgcrypt 1.5.3:

# cryptsetup luksFormat /dev/loop0 --hash whirlpool -c aes-cbc-plain -s 128
# cryptsetup luksFormat /dev/loop1 --hash sha1 -c aes-cbc-plain -s 128
# cryptsetup luksFormat /dev/loop2 --hash whirlpool -c aes-xts-essiv:sha256 -s 
256
# cryptsetup luksFormat /dev/loop3 --hash sha1 -c aes-xts-essiv:sha256 -s 256
# cryptsetup luksFormat /dev/loop4 --hash whirlpool -c serpent-xts-essiv:sha256 
-s 128
# cryptsetup luksFormat /dev/loop5 --hash sha1 -c serpent-xts-essiv:sha256 -s 
128

and updated to libgcrypt 1.6.0 afterwards. The result was that the whirlpool 
images couldn't be opened any more. 

Original issue reported on code.google.com by eisensh...@gmail.com on 17 Jan 2014 at 7:56

[GoogleCodeExporter]

It not problem in cryptsetup but in libgcrypt. Read
http://www.saout.de/pipermail/dm-crypt/2014-January/003813.html

It is (or better was) bug in gcrypt. It seems that all LUKS devices using 
whirlpool with gcrypt < 1.6.0 are in fact corrupted.

I will try to provide some workaround how to "fix" these devices but it will 
not be trivial.

Original comment by gmazyl...@gmail.com on 17 Jan 2014 at 8:15

[GoogleCodeExporter]

To me it sounds like the data itself on the devices isn't corrupted.  Can't we 
just recover the master key with an older version of libgcrypt and create a new 
LUKS header afterwards with sha1 instead of whirlpool?  I did a reencrypt 
yesterday and it took an awful long time. 

Original comment by eisensh...@gmail.com on 18 Jan 2014 at 9:29

[GoogleCodeExporter]

Yes, just reencryption of header is fine (fortunately key derivation is ok, the 
problem is only in AF filter which only diffuse key store to more sectors) and 
next version will have this option (exactly to solve this problem). But 
currently it is possible only with old gcrypt installed (new one cannot open it 
anymore), if you read thread mentioned above, there is possibility gcrypt will 
provide some more help (to access both whirlpool variants).

For now is the best to use old gcrypt. And I would suggest not to override LUKS 
defaults next time without serious reasons (I found some post on Arch forum 
where someone suggested Whirlpool without explanation why - and people just 
copy & paste it... even SHA1 is still fine here, read FAQ.)

Original comment by gmazyl...@gmail.com on 19 Jan 2014 at 9:28

[GoogleCodeExporter]

The lesson was definitely learned.  I'll keep an eye on the thread.  Thank you 
very much for your effort. :) 

Original comment by eisensh...@gmail.com on 20 Jan 2014 at 12:39

[GoogleCodeExporter]

Workaround for whirlpool gcrypt bug is described in FAQ now

https://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions#8._Issues_wit
h_Specific_Versions_of_cryptsetup

Original comment by gmazyl...@gmail.com on 14 Jun 2014 at 3:53

• Changed state: Done