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@xxxxxxxxx> 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@xxxxxxxx > >>>http://www.saout.de/mailman/listinfo/dm-crypt > >>> > >>_______________________________________________ > >>dm-crypt mailing list > >>dm-crypt@xxxxxxxx > >>http://www.saout.de/mailman/listinfo/dm-crypt > > > _______________________________________________ > 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 If it's in the news, don't worry about it. The very definition of "news" is "something that hardly ever happens." -- Bruce Schneier _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
