Re: [dm-crypt] Incidentaly partitioned LUKS device - header lost?

[Arno Wagner <arno@wagner.name>]

Hi Bernd,

you are welcome. There are quite a few helpful people on 
this list, I was just the first one to see this.

Regards,
Arno

On Sat, Jul 02, 2016 at 22:06:05 CEST, Bernd Brägelmann wrote:
> Hi Arno,
> 
> now i can cope better with this situation - as you came to the same
> conclusion. Thanks for your kind support.
> 
> Cheers,
> 
> Bernd
> 
> -- 
> Bernd Brägelmann FA für Radiologie
> Robert-Koch-Str. 42 - 28277 Bremen
> fon: +49 15141457796 PGP: BCA853F8
> 
> 
> On 07/02/2016 08:55 PM, Arno Wagner wrote:
> > 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@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