|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
On Sat, Oct 08, 2011 at 07:42:09PM +0200, Nico Gevers wrote:Actually, you lost the full key, due to the anti-forensic properties
> 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.
of LUKS key storage. Hanginf a few bits anywhere in the keyslot is
enough to make the master-key irrecoverable. This is by design.
No idea what overwrites 0x1000-0x13300, except possibly the
No. The key that was lost is the master key, encrypted with
> 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
your passphrase and "streched" to the full keyslot size.
If a reconstruction as you suggest were possible, disabling
old passphrases would be impossible.
Should not cause this. Some versions of Ubuntu have a problem that
> 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.
they offer to create new LUKS partitions during install in unclear
language, leading people to belive their existing LUKS containers
would be activated, but that is about it AFAIK.
So what you see should not happen. Read errors from the disk
would also show up differently. Has maybe somebody else had
access to that disk?
Since you ran fdisk, it is likely impossible to find out anything from
the change-pattern now.
> 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
> 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
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 mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
[DM Devel] [Fedora Desktop] [ATA RAID] [Fedora Marketing] [Fedora Packaging] [Fedora SELinux] [Yosemite News] [Yosemite Photos] [KDE Users] [Fedora Tools] [Fedora Docs]