Bug 243086 - Hash algorithm produces different encryption key after upgrade FC5 -> F7
Hash algorithm produces different encryption key after upgrade FC5 -> F7
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: cryptsetup-luks (Show other bugs)
7
i386 Linux
low Severity high
: ---
: ---
Assigned To: Till Maas
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-06-07 05:06 EDT by Adalbert Prokop
Modified: 2007-11-30 17:12 EST (History)
5 users (show)

See Also:
Fixed In Version: 1.0.5-4.fc7.1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-08-29 13:29:36 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Adalbert Prokop 2007-06-07 05:06:36 EDT
Description of problem:
Yesterday I have upgraded from FC5 to F7 - complete new installation, not a
system update. Since then I cannot create an encryption layer for my SATA drive
which I have created with FC5. dmsetup shows a different key after cryptsetup
has setup the device.

Version-Release number of selected component (if applicable):
cryptsetup-luks-1.0.3-4.fc7

How reproducible:

Under FC5 (and Knoppix 5.2) do:
# cat key|cryptsetup -c aes-cbc-essiv:sha256 create _dev_sda1 /dev/sda1
# dmsetup --showkeys table _dev_sda1
0 976768002 crypt aes-cbc-essiv:sha256 <key1> 0 8:1 0

Under F7 do:
# cat key|cryptsetup -c aes-cbc-essiv:sha256 create _dev_sdc1 /dev/sdc1
# dmsetup --showkeys table _dev_sdc1
0 976768002 crypt aes-cbc-essiv:sha256 <key2> 0 8:33 0

But I can use dmsetup directly, along with the table I obtained with Knoppix, to
setup the encryption.

# dmsetup create _dev_sdc1 <table_file_from_knoppix>

I have tried different hashing algorithms (plain, md4, md5, ripemd160, sha1,
tiger192). They all produces different keys (which is really fine...) but none
produces <key1> which I need to access my data.

Remark: in F7 device names have changed, that's why sda becomes sdc. I have to
use Knoppix, because FC5 does not exist any more on my hard drives.
Comment 1 Adalbert Prokop 2007-06-07 07:32:59 EDT
I forgot to report that another partition (a PATA drive, previously hdc) is
working just fine, before the upgrade to F7 and hereafter. I use exactly the
same procedure as described above.
Comment 2 Adalbert Prokop 2007-07-21 04:26:07 EDT
Anyone reading this? Suggestions? Hints? Request of additional information?
Comment 3 Till Maas 2007-08-17 09:00:11 EDT
(In reply to comment #2)
> Anyone reading this? Suggestions? Hints? Request of additional information?

Do you still have this problem? Can you show me an example with the complete
table for an example key, I do not have any FC5 to reproduce this on available atm.
Comment 4 Till Maas 2007-08-17 09:23:03 EDT
Can you test cryptsetup-luks 1.0.5 from updates-testing (fc7)? "yum install
--enablerepo updates-testing update cryptsetup-luks"? It gives me the same table
that Knoppix 5.2 gives for the password "Secret".
Comment 5 Adalbert Prokop 2007-08-25 09:59:13 EDT
As you suggested I installed cryptsetup-luks-1.0.5-4.fc7.1.i386.rpm from
updates/testing and this bug disappeared. Now cryptsetup produces applicable
keys. Thank you for the hint.

How was this problem solved? Version upgrade, removing patch2 (as I saw in the
changelog) or just magic? ;)
Comment 6 Till Maas 2007-08-28 11:55:02 EDT
(In reply to comment #5)

> How was this problem solved? Version upgrade, removing patch2 (as I saw in the
> changelog) or just magic? ;)

I guess it was something that happened upstream, patch2 did not change anything
in the beheaviour of cryptsetup.
Comment 7 Fedora Update System 2007-08-29 13:29:29 EDT
cryptsetup-luks-1.0.5-4.fc7.1 has been pushed to the Fedora 7 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.