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

Sven Eschenberg sven at whgl.uni-frankfurt.de
Tue Jan 10 10:06:34 CET 2017


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.

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
>


More information about the dm-crypt mailing list