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 -- 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
