[dm-crypt] Decrypting a drive; says a correct password is "incorrect"

Sven Eschenberg sven at whgl.uni-frankfurt.de
Tue Jan 10 11:23:41 CET 2017


Hi Arno,

You are right, the first block of zeros with 200 bytes length should 
have told me already. Seems I was still a little sleepy ;-).

Regards

-Sven

Am 10.01.2017 um 10:22 schrieb Arno Wagner:
> On Tue, Jan 10, 2017 at 10:06:34 CET, Sven Eschenberg wrote:
>> Hi there,
>>
>> Oversimplified: Your known and correct password is used to convert
>> the on disk keyslot data to generate the actual drive key. Now, if
>> you had the masterkey at hand, you'd have no problems decrypting the
>> drive, if you had a header backup that is still functional, you
>> could retrieve the key with the correct password aswell.
>>
>> If your keyslot is damaged, your password is of no particular use.
>> it does not really matter if you'd try to bruteforce the masterkey,
>> or bruteforce the keyslot material.
>>
>> Assuming they keyslot is mostly intact a brute on the damaged parts
>> could be an interesting option (say you had some bit flips and know
>> their positions).
>>
>> But looking at the output, my feeling is there would be no gain in
>> comparison to bruteforcing the masterkey itself.
>
> Actually, brute-forcing the holes in the keyslot, which seems to
> be about 8kB, is massively harder than brute-forcing a 256 bit key.
> That 256bit key may just withing reach if you put all matter and
> energy of the universe on it and give it a few hundred billion years.
>
> Regards,
> Arno
>
>
>
>
>> Regards
>>
>> -Sven
>>
>>
>> Am 10.01.2017 um 09:47 schrieb K Mmmm:
>>> Thanks for your help, Bob. I have run the keyslot checker, and there
>>> appears to be damage.
>>>
>>> I read in many places that this means the data is simply
>>> irrecoverable. But I don't understand how that could be so. Assuming I
>>> know my password, couldn't I theoretically brute-force each of these
>>> areas where entropy is low?  Is it because there are likely to be
>>> other areas with low entropy that are not detected by the checker?
>>> Would changing the sector size help? Or, is my understanding of hard
>>> disks just so bare, that I fail to realize how difficult this would
>>> be?  If nobody answers, I'll assume it's hopeless, as based on the
>>> following output, this is what my inclination is to believe. If
>>> someone has a "wild idea" (the possibility of recovering the key from
>>> RAM is long gone), then I am certainly willing to try it -- even if it
>>> takes a decade or so to unlock. It's a crypto wallet with just enough
>>> to pay off my first year of medical school loans...
>>>
>>> root at pony:/home/m/cryptsetup-master/misc/keyslot_checker#
>>> ./chk_luks_keyslots /dev/sdb5
>>>
>>> parameters (commandline and LUKS header):
>>>  sector size: 512
>>>  threshold:   0.900000
>>>
>>> - processing keyslot 0:  start: 0x001000   end: 0x03f800
>>>  low entropy at: 0x005000    entropy: 0.000000
>>>  low entropy at: 0x005200    entropy: 0.000000
>>>  low entropy at: 0x005400    entropy: 0.000000
>>>  low entropy at: 0x005600    entropy: 0.000000
>>>  low entropy at: 0x005800    entropy: 0.000000
>>>  low entropy at: 0x005a00    entropy: 0.000000
>>>  low entropy at: 0x005c00    entropy: 0.000000
>>>  low entropy at: 0x005e00    entropy: 0.000000
>>>  low entropy at: 0x038000    entropy: 0.000000
>>>  low entropy at: 0x038200    entropy: 0.000000
>>>  low entropy at: 0x038400    entropy: 0.000000
>>>  low entropy at: 0x038600    entropy: 0.000000
>>>  low entropy at: 0x038800    entropy: 0.000000
>>>  low entropy at: 0x038a00    entropy: 0.000000
>>>  low entropy at: 0x038c00    entropy: 0.000000
>>>  low entropy at: 0x038e00    entropy: 0.000000
>>> - 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
>>>
>>> An example of one of these points with low entropy, using verbose output:
>>>
>>>  low entropy at: 0x038600    entropy: 0.000000
>>>  Binary dump:
>>>  0x038600  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
>>>  0x038610  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
>>>  0x038620  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
>>>  0x038630  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
>>>  0x038640  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
>>>  0x038650  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
>>>  0x038660  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
>>>  0x038670  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
>>>  0x038680  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
>>>  0x038690  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
>>>  0x0386a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
>>>  0x0386b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
>>>  0x0386c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
>>>  0x0386d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
>>>  0x0386e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
>>>  0x0386f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
>>>  0x038700  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
>>>  0x038710  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
>>>  0x038720  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
>>>  0x038730  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
>>>  0x038740  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
>>>  0x038750  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
>>>  0x038760  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
>>>  0x038770  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
>>>  0x038780  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
>>>  0x038790  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
>>>  0x0387a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
>>>  0x0387b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
>>>  0x0387c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
>>>  0x0387d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
>>>  0x0387e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
>>>  0x0387f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
>>>
>>>
>>>
>>> On Wed, Jan 4, 2017 at 9:34 PM, K Mmmm <1800ponysauce at gmail.com> wrote:
>>>> Hello everyone..
>>>>
>>>> About 6 months ago one of my encrypted drives crashed during a brief data
>>>> transfer I was doing. Because it was just a transfer, I did not have the
>>>> keys backed up for this particular hard drive. I do not have another backup
>>>> copy of the data contained in this drive. However it is extremely important
>>>> to my livelihood. This listserv is really my last hope.
>>>>
>>>> Using a platter switch, I was able to copy most of the data to a new hard
>>>> disk. Fortunately, there does appear to be a valid version of a LUKS header
>>>> still intact. However, the password I was using isn't working. It does use
>>>> some special characters, but even the alternates for those characters on
>>>> other locales aren't working. I guess I am first wondering if it is possible
>>>> the LUKS header has changed somehow? If so, can I use the existing data on
>>>> the drive to help me in a keysearch? Surely, some part of this header must
>>>> be relevant to me, even if it is different? ... Is it definitely possible
>>>> for it to have changed?  ... Or could it be something else, e.g. could a
>>>> change in blocksize during the platter switch between hard drives have
>>>> changed the key? The original hard drive originated from a ~2011 laptop
>>>> running Ubuntu 14~. Most of my password guesses were from Ubuntu 16.
>>>>
>>>> If you would like more information (the actual header, partition layout,
>>>> etc.), see this thread:
>>>>
>>>> https://ubuntuforums.org/showthread.php?t=2346612
>>>>
>>>> I think the partition layout might be relevant, as there is only a 2 space
>>>> between the EXT and Linux partitions.
>>>>
>>>> At this point I am trying to gather as many ideas as possible. If there is
>>>> something crazy you've thought of which could be possible, but have never
>>>> seen yet, please suggest it and I will most likely try to investigate it.
>>>> This data is extremely important for my livelihood.
>>>>
>>>> Another thread:
>>>> http://askubuntu.com/questions/848429/why-cant-i-unlock-an-image-recovery-of-my-encrypted-disk-despite-using-the-cor
>>>>
>>>> Even something as simple as being able to programatically change locales
>>>> without having to log-in and out could help a lot. The update-locale command
>>>> does not work without loging in and out... A script like that, or just
>>>> something a little less brute-force than brute-force-luks (which I've
>>>> tried), would be very useful.
>>>>
>>>> Currently booting from an Ubuntu 14 live disk. hoping it could be a
>>>> locale/OS-version problem since the password did use special characters and
>>>> I may have changed the locale to Portuguese/Brazilian... although it's
>>>> unlikely.
>>>>
>>>> Thanks,
>>>> Steve
>>> _______________________________________________
>>> dm-crypt mailing list
>>> dm-crypt at saout.de
>>> http://www.saout.de/mailman/listinfo/dm-crypt
>>>
>> _______________________________________________
>> dm-crypt mailing list
>> dm-crypt at saout.de
>> http://www.saout.de/mailman/listinfo/dm-crypt
>


More information about the dm-crypt mailing list