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.
