Most likely scenario: Something else changed in the password-input
chain. Do you have any non-ISO-7bit chars in your passphrase? These
will change their binary value when going to Unicode. You
mau also have characters switched because of a keyboard-layout
issue.
The FAQ has more info in item 1.2
Also note that asking a question on a mailing-list without
subscribing is a sure way to miss answers and generally
not a good idea. What you do is to subscribe, ask, and
when things are cleared up, unsubscribe.
Arno
On Mon, Aug 11, 2014 at 03:58:36 CEST, jeff.esquivel@xxxxxxxxx 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@xxxxxxxx
> http://www.saout.de/mailman/listinfo/dm-crypt
--
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@xxxxxxxxxxx
GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. - Plato
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
