[dm-crypt] Can't access a LUKS encrypted partition

* [dm-crypt] Can't access a LUKS encrypted partition
@ 2014-08-11  1:58 jeff.esquivel
  2014-08-11  5:37 ` Konstantin Bläsi
  2014-08-11 10:07 ` Arno Wagner
  0 siblings, 2 replies; 10+ messages in thread
From: jeff.esquivel @ 2014-08-11  1:58 UTC (permalink / raw)
  To: dm-crypt

[-- Attachment #1: Type: text/plain, Size: 6222 bytes --]

Hi everyone,

I'm trying to access an encrypted partition on an external USB hard drive
(WD My Passport Slim) but I get this:

$ sudo cryptsetup -v luksOpen /dev/sdb1 securepart
Enter passphrase for /dev/sdb1:
No key available with this passphrase.

Some background information on the issue:

DAY 1

I received this new external hard drive some days ago, the first thing I
did was run badblocks on it (while at the same time writing it with random
data), like this (on that day I had other USB disk plugged in before, which
is why I'm was working with sdc instead of sdb as stated above):

$ sudo /sbin/badblocks -c 10240 -s -w -t random -v /dev/sdc

Then I created a new DOS partition table (using fdisk) and then a new
primary partition that spanned the whole disk, and after that I created a
new LUKS volumen on the new partition as this:

$ sudo cryptsetup --verify-passphrase luksFormat /dev/sdc1 -c aes -s 256 -h
sha256
$ sudo cryptsetup luksOpen /dev/sdc1 secure
$ sudo mkfs -t ext4 -m 0 /dev/mapper/secure
$ sudo cryptsetup luksClose secure

I then disconnected and reconnected the disk to see if Ubuntu (I'm using
14.04 on 64 bits) would recognize it. It did and asked me for the
passphrase on a window, I entered it and worked correctly, I then proceeded
to copy some unimportant big files (more than 50GB) from the other USB disk
I had plugged in. Another detail which may be important, I had the LUKS
disk connected through a USB  hub (which also has an ethernet card on the
same physical device).

DAY 2

I connected both disks again, when Ubuntu asked me for the LUKS passphrase
I entered it and it worked as expected, I proceeded to copy some more
unimportant files from the other USB disk to the LUKS partition (about
150GB at least). I disconnected and reconnected the disk at least twice
this day and everything worked OK.

DAY 3

Same as day before, the encrypted partition unlocked without a problem, I
proceeded to copy all of my important files from the other USB disk to the
encrypted partition (about 200GB), this day I used the USB hub/ethernet
card again to connect the external hard drive that had the LUKS partition
(I mention this because I also have a wireless mouse that works with an USB
receiver that was plugged to the same USB hub and noticed some laggyness
when using this mouse, I thought it was related to the amount of bandwidth
being used by the drive while copying all of my files).

DAY 4

I plugged the external hard drive, Ubuntu asks me for my passphrase and it
won't work, at first I thought it was a typo or something and tried again,
but failed again, I then typed the passphrase on a text editor and then
cut+paste it into the windows that was asking me for it and it didn't work
either. I tried one more time, this time from the command line, and I got
the error shown above ("No key available...").

THINGS I'VE TRIED

I search the Internet for a possible cause and fix, I found some threads on
this list (and other places) where people had inadvertently overwritten
their LUKS header while booting another distro that thought the LUKS
partition was some swap partition, but I don't think this applies to me as
1) There was never a swap partition on this disk 2) I haven't booted or
even connected this specific hard drive to other distro/computer.

I also ran the recommended isLuks command and the keyslot_checker tool to
see if there was any indication of header corruption, but it seems like
that's not the issue:

$ sudo cryptsetup -v isLuks /dev/sdb1
Command successful.

$ sudo ./chk_luks_keyslots -v /dev/sdb1

parameters (commandline and LUKS header):
  sector size: 512
  threshold:   0.900000

- processing keyslot 0:  start: 0x001000   end: 0x020400
- processing keyslot 1:  keyslot not in use
- processing keyslot 2:  keyslot not in use
- processing keyslot 3:  keyslot not in use
- processing keyslot 4:  keyslot not in use
- processing keyslot 5:  keyslot not in use
- processing keyslot 6:  keyslot not in use
- processing keyslot 7:  keyslot not in use

Also, this is the output from luksDump:

$ sudo cryptsetup luksDump /dev/sdb1
LUKS header information for /dev/sdb1

Version:           1
Cipher name:       aes
Cipher mode:       cbc-plain
Hash spec:         sha256
Payload offset:    4096
MK bits:           256
MK digest:         a5 61 25 03 2e 98 5a 48 d1 62 c6 fc dd ca 1f b8 9d c5 09
a8
MK salt:           b4 6f 62 bc 0c 81 6a 57 6e 6f 21 54 70 df 89 62
                   0a 69 e9 eb 38 6c 45 8d 82 a2 85 64 3f c7 09 9d
MK iterations:     27875
UUID:              e747b7df-3086-455e-9f8d-71cb76d1f534

Key Slot 0: ENABLED
    Iterations:             123076
    Salt:                   af cc 4c eb 24 e5 0b 7a 6d fd b1 4c d1 da 3a f1
                              97 bb 96 6d 65 a4 f5 36 68 66 e9 40 b8 70 f9
d1
    Key material offset:    8
    AF stripes:                4000
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

So, up to this moment I have three hypothesis:

1) There is something that changed on my system that broke cryptsetup's
behaviour making it unable to open my encrypted partition (is this
possible? for example, if there was some module missing from my kernel or
if I installed some new package that could have changed something).

2) I entered my passphrase incorrectly when luksFormat'ing, and then
proceeded to enter it incorrectly the next 4 times I unlocked the partition
(just in case, I generated about 700 different possible combinations using
the most common typos I could've made when entering my passphrase and then
used the crypt_dict tool to test them unsuccessfully).

3) There was some issue with the hub I was using which meant that some data
could have been written incorrectly to encrypted partition's header (is
this possible? I mean, I was copying files to the partition, I don't see
how that could affect the header, but maybe when unmounting the partition
the header gets written to, I don't know).

Any help would be greatly appreciated.

Thank you for your time,

PS: Please CC me, as I'm not subscribed to this list and excuse my english
as I'm s not a native speaker.

-- 
Jeffrey Esquivel S.

[-- Attachment #2: Type: text/html, Size: 7011 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread