dm-crypt 1.6.6 is unable to open partition with password stored in file

[GoogleCodeExporter]

What steps will reproduce the problem?
1. cat passfile | /sbin/cryptsetup --debug luksOpen /dev/sdd2 cr_extra1

What is the expected output? 
Opened partition.

What do you see instead?
Command failed with code 1: No key available with this passphrase.

What version of the product are you using? 
1.6.6

On what operating system?
openSUSE 13.2

Please provide any additional information below.
The partition was encrypted when I was using openSUSE 11.4. Now, after upgrade 
to 13.2, with new dm-crypt I am unable to access this partition. The full 
output:
# cryptsetup 1.6.6 processing "/sbin/cryptsetup -d passfile --debug luksOpen 
/dev/sdd2 cr_extra1"
# Running command open.
# Locking memory.
# Installing SIGINT/SIGTERM handler.
# Unblocking interruption on signal.
# Allocating crypt device /dev/sdd2 context.
# Trying to open and read device /dev/sdd2.
# Initialising device-mapper backend library.
# Trying to load LUKS1 crypt type from device /dev/sdd2.
# Crypto backend (gcrypt 1.6.1) initialized.
# Detected kernel Linux 3.16.6-2-desktop x86_64.
# Reading LUKS header of size 1024 from device /dev/sdd2
# Key length 32, device size 1103108096 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.
# Password retry count set to 1.
# Activating volume cr_extra1 [keyslot -1] using keyfile passfile.
# dm version   OF   [16384] (*1)
# dm versions   OF   [16384] (*1)
# Detected dm-crypt version 1.13.0, dm-ioctl version 4.27.0.
# Device-mapper backend running with UDEV support enabled.
# dm status cr_extra1  OF   [16384] (*1)
# File descriptor passphrase entry requested.
# Trying to open key slot 0 [ACTIVE_LAST].
# Reading key slot 0 area.
# Using userspace crypto wrapper to access keyslot area.
# 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].
No key available with this passphrase.
# Releasing crypt device /dev/sdd2 context.
# Releasing device-mapper backend.
# Unlocking memory.
Command failed with code 1: No key available with this passphrase.

I tried my luck with Linux Mint 17, which features dm-crypt 1.6.1 and the same 
command succeeded (as before with OS 11.4), maybe output is bit longer, but it 
works.

Original issue reported on code.google.com by pilichow...@gmail.com on 8 Nov 2014 at 2:42

[GoogleCodeExporter]

Can you paste luksDump of the device (you can wipe fingerprint, I am interested 
in used algorithms)? Is Whirlpool hash used there?

Original comment by gmazyl...@gmail.com on 8 Nov 2014 at 4:40

[GoogleCodeExporter]

XXXXXX -- info removed (by me). Yes, there is whirlpool.

Btw. luckily I was able to downgrade cryptsetup and its libs from 1.6.6 to 
1.6.2, and it works OK. The output comes from 1.6.2.

Version:        1
Cipher name:    aes
Cipher mode:    cbc-essiv:sha256
Hash spec:      whirlpool
Payload offset: XXXXXXXXXXXX

Key Slot 0: ENABLED
            XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

Original comment by pilichow...@gmail.com on 8 Nov 2014 at 10:36

[GoogleCodeExporter]

ok, that explains it.

The old gcrypt Whirlpool implementation is flawed. With upgrade to gcrypt 1.6.x 
it was fixed with the nasty side effect of incompability.

Please read FAQ item 8.3, there is also description how to "fix" it, 
https://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions#8._Issues_wit
h_Specific_Versions_of_cryptsetup

This is not cryptsetup bug but known gcrypt problem.

Original comment by gmazyl...@gmail.com on 8 Nov 2014 at 10:50

• Changed state: Done

[GoogleCodeExporter]

Thank you very much. FAQ states "This shows one serious risk of using rarely 
used settings." and several other times in the sense Whirlpool was not used 
often. I don't have any data what is used often -- what hash function it would 
be (and be a solid hash function as well).

Original comment by pilichow...@gmail.com on 9 Nov 2014 at 7:21

[GoogleCodeExporter]

Well, Arno probably meant "rarely used with gcrypt". Whirlpool is solid hash, I 
was very surprised such bug exist for so long time there.
That's why test vectors and regression tests are so important...

FYI: you can read the whole cryptsetup whirlpool story here
http://thread.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/7164/focus=717
7

Original comment by gmazyl...@gmail.com on 9 Nov 2014 at 8:59

[GoogleCodeExporter]

Sorry to bother you again, but after preparing all the stuff for the switch 
(reencryption) I found such problems:

* the reencrypt tool does not support reading pass phrases from the file as 
cryptsetup -- it means the data from cryptsetup cannot be used (or I miss 
something)
* as I understand I should upgrade to 1.6.6, and using it I should do the 
reencryption, right? I used `cat`, and I got this:

# cat passfile | cryptsetup-reencrypt --keep-key --hash whirlpool /dev/sdd1
WARNING: this is experimental code, it can completely break your data.
No key available with this passphrase.

Since 1.6.2 recognizes whirpool as buggy version, I cannot do the switch with 
it.

What can I do? Thank you very much in advance for your help and patience.

Original comment by pilichow...@gmail.com on 11 Nov 2014 at 9:49

[GoogleCodeExporter]

cryptsetup-reencrypt both reading from keyufile and from std out but only if 
there is only one keyslot.

I suggest to reencrypt header with SHA1 (or SHA256). With whirlpool you will 
have always the problem to open it on some older/new system, depend on which 
implementation is available.

Whatever, these works:

echo "password" | cryptsetup-reencrypt /dev/<device> -h sha1 --keep-key

or
echo -n "password" >key
cryptsetup-reencrypt /dev/<device> -h sha1 --keep-key -d key

(with the last version - 1.6.6)

See the FAQ - if you have new version of cryptsetup (1.6.6) and new version of 
gcrypt, use the trick to change hash version in header to whirlpool_gcryptbug:
     echo -n -e 'whirlpool_gcryptbug\0' | dd of=<luks device> bs=1 seek=72 conv=notrunc

Then you should be able to use reencrypt (and backup header first!).

Original comment by gmazyl...@gmail.com on 11 Nov 2014 at 7:42

[GoogleCodeExporter]

Thank you very much for your help, I just realized that something different 
than whirlpool is a must, because no version support double meaning of this 
algorithm at the same time.
This time everything worked just fine.

Thank you once again.

Original comment by pilichow...@gmail.com on 12 Nov 2014 at 4:18