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

[Arno Wagner <arno@wagner.name>]

Hi Sven,

no problem, I was so tired that I had to look 3 times,
hence the correct result (I think) ;-)

Regards,
Arno

On Tue, Jan 10, 2017 at 11:23:41 CET, Sven Eschenberg wrote:
> 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@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
> >
> _______________________________________________
> 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