* [dm-crypt] Decrypting a drive; says a correct password is "incorrect" @ 2017-01-05 2:34 K Mmmm 2017-01-06 15:57 ` Robert Nichols 2017-01-10 8:47 ` K Mmmm 0 siblings, 2 replies; 12+ messages in thread From: K Mmmm @ 2017-01-05 2:34 UTC (permalink / raw) To: dm-crypt [-- Attachment #1: Type: text/plain, Size: 2496 bytes --] 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 [-- Attachment #2: Type: text/html, Size: 2948 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [dm-crypt] Decrypting a drive; says a correct password is "incorrect" 2017-01-05 2:34 [dm-crypt] Decrypting a drive; says a correct password is "incorrect" K Mmmm @ 2017-01-06 15:57 ` Robert Nichols 2017-01-10 8:47 ` K Mmmm 1 sibling, 0 replies; 12+ messages in thread From: Robert Nichols @ 2017-01-06 15:57 UTC (permalink / raw) To: dm-crypt On 01/04/2017 08:34 PM, K Mmmm wrote: > 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. Did "most of the data" include the entire ~2MB LUKS header? You need at least the first 256KB to get all the stripes of the first keyslot. If that data is not all bit-for-bit perfect, the master key cannot be recovered and your data cannot be decrypted. You can look at section 4.2 of the cryptsetup FAQ at <https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions#4-troubleshooting> for information on how to build and run a keyslot checker that can test for obvious damage to the keyslots ("obvious" meaning "data with low entropy appearing in places that should appear random"). > I think the partition layout might be relevant, as there is only a 2 > space between the EXT and Linux partitions. Your partition layout is fine. Logical partitions (numbers 5 and higher) exist within the extended partition. All that is needed is space for the 1-sector extended partition header before the start of partition 5. -- Bob Nichols "NOSPAM" is really part of my email address. Do NOT delete it. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [dm-crypt] Decrypting a drive; says a correct password is "incorrect" 2017-01-05 2:34 [dm-crypt] Decrypting a drive; says a correct password is "incorrect" K Mmmm 2017-01-06 15:57 ` Robert Nichols @ 2017-01-10 8:47 ` K Mmmm 2017-01-10 9:06 ` Sven Eschenberg ` (2 more replies) 1 sibling, 3 replies; 12+ messages in thread From: K Mmmm @ 2017-01-10 8:47 UTC (permalink / raw) To: dm-crypt 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [dm-crypt] Decrypting a drive; says a correct password is "incorrect" 2017-01-10 8:47 ` K Mmmm @ 2017-01-10 9:06 ` Sven Eschenberg 2017-01-10 9:22 ` Arno Wagner 2017-01-10 9:18 ` Arno Wagner 2017-01-10 15:43 ` Robert Nichols 2 siblings, 1 reply; 12+ messages in thread From: Sven Eschenberg @ 2017-01-10 9:06 UTC (permalink / raw) To: dm-crypt 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. 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 > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [dm-crypt] Decrypting a drive; says a correct password is "incorrect" 2017-01-10 9:06 ` Sven Eschenberg @ 2017-01-10 9:22 ` Arno Wagner 2017-01-10 10:23 ` Sven Eschenberg 0 siblings, 1 reply; 12+ messages in thread From: Arno Wagner @ 2017-01-10 9:22 UTC (permalink / raw) To: dm-crypt 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [dm-crypt] Decrypting a drive; says a correct password is "incorrect" 2017-01-10 9:22 ` Arno Wagner @ 2017-01-10 10:23 ` Sven Eschenberg 2017-01-10 13:58 ` Arno Wagner 0 siblings, 1 reply; 12+ messages in thread From: Sven Eschenberg @ 2017-01-10 10:23 UTC (permalink / raw) To: dm-crypt 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 > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [dm-crypt] Decrypting a drive; says a correct password is "incorrect" 2017-01-10 10:23 ` Sven Eschenberg @ 2017-01-10 13:58 ` Arno Wagner 0 siblings, 0 replies; 12+ messages in thread From: Arno Wagner @ 2017-01-10 13:58 UTC (permalink / raw) To: dm-crypt 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [dm-crypt] Decrypting a drive; says a correct password is "incorrect" 2017-01-10 8:47 ` K Mmmm 2017-01-10 9:06 ` Sven Eschenberg @ 2017-01-10 9:18 ` Arno Wagner 2017-01-10 15:43 ` Robert Nichols 2 siblings, 0 replies; 12+ messages in thread From: Arno Wagner @ 2017-01-10 9:18 UTC (permalink / raw) To: dm-crypt On Tue, Jan 10, 2017 at 09:47:30 CET, K Mmmm wrote: > 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? Yes, you could in theory. In your case, this seems to be 8kB missing. Brute-forcing 8kB is infeasible in this universe, not enough matter, energy and remaining lifetime of the universe, regardles of whether it goes into heat-death or collapse. So in thery, yes, in practice no. > 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... Sorry, if this is all you have, then there is no possibility to recover it. The key-slots are designed to make recovery even on slight damage infeasible, it is an anti-forensic measure. It works against you here. Regards, Arno > 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 -- 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [dm-crypt] Decrypting a drive; says a correct password is "incorrect" 2017-01-10 8:47 ` K Mmmm 2017-01-10 9:06 ` Sven Eschenberg 2017-01-10 9:18 ` Arno Wagner @ 2017-01-10 15:43 ` Robert Nichols 2017-01-11 1:47 ` Arno Wagner 2 siblings, 1 reply; 12+ messages in thread From: Robert Nichols @ 2017-01-10 15:43 UTC (permalink / raw) To: dm-crypt On 01/10/2017 02:47 AM, K Mmmm wrote: > 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 That would definitely make it worth sending the drive to a professional data recovery company and ask them to try to recover just those 16 missing sectors. -- Bob Nichols "NOSPAM" is really part of my email address. Do NOT delete it. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [dm-crypt] Decrypting a drive; says a correct password is "incorrect" 2017-01-10 15:43 ` Robert Nichols @ 2017-01-11 1:47 ` Arno Wagner 2017-01-11 2:17 ` Robert Nichols 0 siblings, 1 reply; 12+ messages in thread From: Arno Wagner @ 2017-01-11 1:47 UTC (permalink / raw) To: dm-crypt On Tue, Jan 10, 2017 at 16:43:46 CET, Robert Nichols wrote: > On 01/10/2017 02:47 AM, K Mmmm wrote: [...] > That would definitely make it worth sending the drive to a professional > data recovery company and ask them to try to recover just those 16 > missing sectors. Well, maybe. But keep in mind this will only help if they get all of them completely and there is no other relevant damage. Might also be very expensive if there is surface damage to the platters. Regards, Arno -- 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [dm-crypt] Decrypting a drive; says a correct password is "incorrect" 2017-01-11 1:47 ` Arno Wagner @ 2017-01-11 2:17 ` Robert Nichols 0 siblings, 0 replies; 12+ messages in thread From: Robert Nichols @ 2017-01-11 2:17 UTC (permalink / raw) To: dm-crypt On 01/10/2017 07:47 PM, Arno Wagner wrote: > On Tue, Jan 10, 2017 at 16:43:46 CET, Robert Nichols wrote: >> On 01/10/2017 02:47 AM, K Mmmm wrote: > [...] >> That would definitely make it worth sending the drive to a professional >> data recovery company and ask them to try to recover just those 16 >> missing sectors. > > Well, maybe. But keep in mind this will only help if they > get all of them completely and there is no other relevant > damage. > > Might also be very expensive if there is surface damage > to the platters. So is a first year in medical school, regardless of surface damage. But of course even if the LUKS keyslot can be recovered, there is still no guarantee that the filesystem and digital wallet are intact. -- Bob Nichols "NOSPAM" is really part of my email address. Do NOT delete it. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [dm-crypt] Decrypting a drive; says a correct password is "incorrect" @ 2017-01-05 16:22 Arno Wagner 0 siblings, 0 replies; 12+ messages in thread From: Arno Wagner @ 2017-01-05 16:22 UTC (permalink / raw) To: dm-crypt Please do not send HTML-email to this list. Regards, Arno -- 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2017-01-11 2:17 UTC | newest] Thread overview: 12+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2017-01-05 2:34 [dm-crypt] Decrypting a drive; says a correct password is "incorrect" K Mmmm 2017-01-06 15:57 ` Robert Nichols 2017-01-10 8:47 ` K Mmmm 2017-01-10 9:06 ` Sven Eschenberg 2017-01-10 9:22 ` Arno Wagner 2017-01-10 10:23 ` Sven Eschenberg 2017-01-10 13:58 ` Arno Wagner 2017-01-10 9:18 ` Arno Wagner 2017-01-10 15:43 ` Robert Nichols 2017-01-11 1:47 ` Arno Wagner 2017-01-11 2:17 ` Robert Nichols -- strict thread matches above, loose matches on Subject: below -- 2017-01-05 16:22 Arno Wagner
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.