From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <bernd@braegelmann.net>
Received: from sb38.braegelmann.net (sb38.braegelmann.net [78.46.45.242])
 (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by mail.server123.net (Postfix) with ESMTPS
 for <dm-crypt@saout.de>; Sat,  2 Jul 2016 20:11:46 +0200 (CEST)
References: <655760b1-5f92-e6f5-50c1-d46edef89cd9@braegelmann.net>
 <20160702102000.GA22828@tansi.org> <20160702102517.GA23072@tansi.org>
 <57779A93.20805@braegelmann.net> <20160702161456.GA24756@tansi.org>
From: =?UTF-8?Q?Bernd_Br=c3=a4gelmann?= <bernd@braegelmann.net>
Message-ID: <577803E0.1050901@braegelmann.net>
Date: Sat, 2 Jul 2016 20:11:44 +0200
MIME-Version: 1.0
In-Reply-To: <20160702161456.GA24756@tansi.org>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [dm-crypt] Incidentaly partitioned LUKS device - header lost?
List-Id: <dm-crypt.saout.de>
List-Unsubscribe: <http://www.saout.de/mailman/options/dm-crypt>,
 <mailto:dm-crypt-request@saout.de?subject=unsubscribe>
List-Archive: <http://www.saout.de/pipermail/dm-crypt/>
List-Post: <mailto:dm-crypt@saout.de>
List-Help: <mailto:dm-crypt-request@saout.de?subject=help>
List-Subscribe: <http://www.saout.de/mailman/listinfo/dm-crypt>,
 <mailto:dm-crypt-request@saout.de?subject=subscribe>
To: dm-crypt@saout.de

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.

So all fucked up - I guess.

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?

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


--=20
Bernd Br=E4gelmann FA f=FCr Radiologie
Robert-Koch-Str. 42 - 28277 Bremen
fon: +49 15141457796 PGP: BCA853F8


On 07/02/2016 06:14 PM, Arno Wagner wrote:
> Hi Bernd,
>=20
> On Sat, Jul 02, 2016 at 12:42:27 CEST, Bernd Br=E4gelmann wrote:
>> Hi Arno,
>>
>> thanks for answering. I created the partition table within /dev/md2 and
>> the raid is still working.
>=20
> Ok, so we ignore the RAID.
> =20
>> My current last hope is that the salt might be in a redundant part of
>> the raid array.=20
>=20
> Those will have gotten synced immediately, RAID inconsistencies
> live only for as long as they are in the write queue. No hope=20
> there.
>=20
> 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=20
> passphrase(s)):
>=20
>   head -c 1k /dev/md2 | hd
>=20
> This allows a manual look of what is left of the LUKS header.
>=20
> Regards,
> Arno
>=20