Re: Incidentaly partitioned LUKS device - header lost?

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

 



Hi Bernd,

On Sat, Jul 02, 2016 at 20:11:44 CEST, Bernd Brägelmann wrote:
> Hi Arno,
> 
> here the requested dump. Looks like the Master Boot Record with "55 aa"
> boot signature. The byterange of the luks mastersalt is basically empty.

Indeed.

> So all fucked up - I guess.

That is my take as well. Unless the header is in some
image-backup or the like somewhere else, there is no 
way to recover this and it is not a question of money
either.

> BTW: What is your guess: Will my grandchildren be able to crack a
> 256-aes-xts file system. What is your guess? Should I long-term store
> the hard discs?

The best attack would be on the master-key directly, ignore
all that LUKS stuff. Lets also assume they have one block
with a known plaintest (e.g. a filsystem master-block) or
an empty inode).  

If we assume quantum computing ever works for problems this 
size (very, very doubtful), maybe the key could be cut down 
to 128 bit.

2^128 is 3.4*10^38    

I think we can safely forget that for the foreseable future.
It will need some "magic" to be discovered that is stronger than
quantum computing, or else there is no way the human race will 
be able to recover your data from that disk. That is as it should 
be, LUKS needs to be secure after all.

Of course, it is possible that AES will turn out to be
trivially breakable, but that seems rather unlikely as well.

Sorry I have no better news, but security and accessibility
are naturally at odds. Just read the items on backup in FAQ 
Section 6 for the next time. LUKS is in principle very safe 
and reliable, but the header and keyslots are its one weak 
spot. There has been a lot of discussion here about doing 
some automatic header backup, but so far no good solution has 
presented itself.

Regards,
Arno

 
> Cheers,
> 
> Bernd
> 
> 
> braegel1 ~ # head -c 1k /dev/md2 | hd
> 00000000  fa b8 00 10 8e d0 bc 00  b0 b8 00 00 8e d8 8e c0
> |................|
> 00000010  fb be 00 7c bf 00 06 b9  00 02 f3 a4 ea 21 06 00
> |...|.........!..|
> 00000020  00 be be 07 38 04 75 0b  83 c6 10 81 fe fe 07 75
> |....8.u........u|
> 00000030  f3 eb 16 b4 02 b0 01 bb  00 7c b2 80 8a 74 01 8b
> |.........|...t..|
> 00000040  4c 02 cd 13 ea 00 7c 00  00 eb fe 00 00 00 00 00
> |L.....|.........|
> 00000050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
> |................|
> *
> 000001b0  00 00 00 00 00 00 00 00  70 57 07 00 00 00 00 00
> |........pW......|
> 000001c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
> |................|
> *
> 000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa
> |..............U.|
> 00000200  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
> |................|
> *
> 00000400
> 
> 
> -- 
> Bernd Brägelmann FA für Radiologie
> Robert-Koch-Str. 42 - 28277 Bremen
> fon: +49 15141457796 PGP: BCA853F8
> 
> 
> On 07/02/2016 06:14 PM, Arno Wagner wrote:
> > Hi Bernd,
> > 
> > On Sat, Jul 02, 2016 at 12:42:27 CEST, Bernd Brägelmann wrote:
> >> Hi Arno,
> >>
> >> thanks for answering. I created the partition table within /dev/md2 and
> >> the raid is still working.
> > 
> > Ok, so we ignore the RAID.
> >  
> >> My current last hope is that the salt might be in a redundant part of
> >> the raid array. 
> > 
> > Those will have gotten synced immediately, RAID inconsistencies
> > live only for as long as they are in the write queue. No hope 
> > there.
> > 
> > Ok, the LUKS superblock (or what is left of it) will be at
> > the start of /dev/md2. Can you post the following (will
> > not compromise your datta, that is protected by the 
> > passphrase(s)):
> > 
> >   head -c 1k /dev/md2 | hd
> > 
> > This allows a manual look of what is left of the LUKS header.
> > 
> > Regards,
> > Arno
> > 
> _______________________________________________
> 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




[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