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

[Arno Wagner <arno@wagner.name>]

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@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@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@saout.de
> >http://www.saout.de/mailman/listinfo/dm-crypt
> >
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
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

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier