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

["Bernd Brägelmann" <bernd@braegelmann.net>]

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
>