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
