Re: Data recovery

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Arno

Thanks for your reply. I made a header backup and had a look at the hex dump. Its about 1.4M so haven't attached it, but can if its useful. The drive was using aes-xts-plain with a 512 bit key. According to the FAQ this means that 1st keyslot starts at 0x1000 and runs until 0x3f800. Having had a look at the dump, I noticed 0x1000 - 0x13300 was fairly regular, and from 0x14000 the dump looked quite random until the end of the keyspace. I guess that means I've lost some of the key.

Excuse my ignorance here, but wouldn't it be possible (in my case) to reverse engineer the data in the keyslot, since I know the original key as well as the iterations and salt value. Could I not regenerate the key hash and insert it back into the header. I could even check the correctness of the key my matching the last half of the bits to the ones in the existing keyslot.

As for how it happened, I wish I knew. All I remember is one morning starting my machine up and being surprised that the external drive wouldn't accept my password. I do remember getting semaphore errors for the first time, and since I'm running ubuntu 11.10 beta, perhaps I did an update that might have caused a hassle some where (perhaps a kernel update or an update to cryptsetup). I wasn't really paying attention since I didn't anticipate anything like this. 

Oh, and here's a dump of the luksDump command. I can attach the header if its useful to anyone.

Version:       1
Cipher name:   aes
Cipher mode:   xts-plain
Hash spec:     sha1
Payload offset: 4040
MK bits:       512
MK digest:     1e 01 d1 96 ba 79 cd 9f d1 cd 7f ee 1c e5 e7 51 ed a7 61 06 
MK salt:       60 32 3e 38 42 1f 5c 05 ce 21 d6 27 ad 23 bf 1e 
                a7 18 13 a7 75 8f 33 f0 f6 f8 25 da 0c e0 af 60 
MK iterations: 9125
UUID:           5048085d-d798-4b4f-902b-88eb2e71fd88

Key Slot 0: ENABLED
Iterations:         36805
Salt:               25 4b 79 50 a4 0b 26 40 85 48 5c d0 28 1b 42 73 
                      7b 59 a7 e6 17 81 94 22 c8 45 de 96 b7 bd 8f f1 
Key material offset: 8
AF stripes:             4000

<the rest of the keyslots are empty>

thanks again
Nico

On Sat, Oct 8, 2011 at 6:22 PM, Arno Wagner <arno@xxxxxxxxxxx> wrote:
On Sat, Oct 08, 2011 at 02:28:28PM +0200, Nico Gevers wrote:
> Hi
>
> I've recently decided to encrypt all my drives using luks, running on ubuntu
> 11.10. I encrypted my external drive, and loaded all my backups onto the
> drive. One morning, I tried accessing the drive, and it wouldn't accept my
> key phrase. I tried a couple of times, even tried some variations, but no
> avail. Then I stupidly thought of running fsck on the drive. I fixed a
> couple of innodes, but then stopped, realising that I was probably doing
> more harm than good.
>
> When I run luksDump on that drive, I get all the expected information. My
> question is: is the header still intact. Is there any chance I can recover
> my data, owing to the fact that luksDump displays, what seems to me, a valid
> header? (I'm assuming that if luksDump shows the information, the header is
> intact).

The header itself may be intact. But the problem here is the keyslots.
If they are damaged, the only thing that can save your data is a header
backup.

What I wonder is why fsck was even willing to run. Due to the encryption,
it will have seen absolutely nothing that looks like a filesystem.
It also is quite possible that it 'fixed' things in the keyslot area.

In addition, there is the question for the reason fo the initial
fail.

So, what you do now is make a header backup (procedure is in the
FAQ) und analyse that. First, find out in which keyslot your key
is (likely the first), then look at the FAQ section on on-disk
format and look at the encrypted keyslot with a hex-dump
tool, e.g. hd. If there is anything looking regular in the
keyslot area, apply procedure for dealing with permanent data
loss, also described in the FAQ.

You can of course ask for further advice here, but it is impossible
to answer your question without looking at that keyslot data.

Arno
--
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@xxxxxxxxxxx
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

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

_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt

[Index of Archives]     [Device Mapper Devel]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux