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

["Konstantin Bläsi" <ktrackfd@googlemail.com>]

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

On 08/11/2014 03:58 AM, jeff.esquivel@gmail.com wrote:
> 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.
>
>
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

Hi,

make sure all required kernel modules are _loaded_ before using
cryptsetup (a few bugs have been discovered lately depending on that
condition).
Did you try some live iso image like systemrescuecd?
I found a case where the latest kbd package (responsible for the
keyboard layout) broke the correct entry of the password:
https://bbs.archlinux.org/viewtopic.php?id=169408

Greetings ;)

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