From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from v1.tansi.org (mail.tansi.org [84.19.178.47]) by mail.server123.net (Postfix) with ESMTP for ; Sat, 2 Jul 2016 23:53:16 +0200 (CEST) Received: from gatewagner.dyndns.org (77-56-144-126.dclient.hispeed.ch [77.56.144.126]) by v1.tansi.org (Postfix) with ESMTPA id 6F989140049 for ; Sat, 2 Jul 2016 23:53:15 +0200 (CEST) Date: Sat, 2 Jul 2016 23:53:15 +0200 From: Arno Wagner Message-ID: <20160702215315.GA28620@tansi.org> References: <655760b1-5f92-e6f5-50c1-d46edef89cd9@braegelmann.net> <20160702102000.GA22828@tansi.org> <20160702102517.GA23072@tansi.org> <57779A93.20805@braegelmann.net> <20160702161456.GA24756@tansi.org> <577803E0.1050901@braegelmann.net> <20160702185548.GA26509@tansi.org> <57781EAD.7000709@braegelmann.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <57781EAD.7000709@braegelmann.net> Subject: Re: [dm-crypt] Incidentaly partitioned LUKS device - header lost? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de Hi Bernd, you are welcome. There are quite a few helpful people on=20 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=E4gelmann wrote: > Hi Arno, >=20 > now i can cope better with this situation - as you came to the same > conclusion. Thanks for your kind support. >=20 > Cheers, >=20 > Bernd >=20 > --=20 > Bernd Br=E4gelmann FA f=FCr Radiologie > Robert-Koch-Str. 42 - 28277 Bremen > fon: +49 15141457796 PGP: BCA853F8 >=20 >=20 > On 07/02/2016 08:55 PM, Arno Wagner wrote: > > Hi Bernd, > >=20 > > On Sat, Jul 02, 2016 at 20:11:44 CEST, Bernd Br=E4gelmann 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 empt= y. > >=20 > > Indeed. > >=20 > >> So all fucked up - I guess. > >=20 > > That is my take as well. Unless the header is in some > > image-backup or the like somewhere else, there is no=20 > > way to recover this and it is not a question of money > > either. > >=20 > >> 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? > >=20 > > 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). =20 > >=20 > > If we assume quantum computing ever works for problems this=20 > > size (very, very doubtful), maybe the key could be cut down=20 > > to 128 bit. > >=20 > > 2^128 is 3.4*10^38 =20 > >=20 > > 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=20 > > be able to recover your data from that disk. That is as it should=20 > > be, LUKS needs to be secure after all. > >=20 > > Of course, it is possible that AES will turn out to be > > trivially breakable, but that seems rather unlikely as well. > >=20 > > Sorry I have no better news, but security and accessibility > > are naturally at odds. Just read the items on backup in FAQ=20 > > Section 6 for the next time. LUKS is in principle very safe=20 > > and reliable, but the header and keyslots are its one weak=20 > > spot. There has been a lot of discussion here about doing=20 > > some automatic header backup, but so far no good solution has=20 > > presented itself. > >=20 > > Regards, > > Arno > >=20 > > =20 > >> 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, > >>> > >>> 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. > >>> > >>> 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 > >>> > >>> Those will have gotten synced immediately, RAID inconsistencies > >>> live only for as long as they are in the write queue. No hope=20 > >>> 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=20 > >>> 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 > >=20 > _______________________________________________ > dm-crypt mailing list > dm-crypt@saout.de > http://www.saout.de/mailman/listinfo/dm-crypt --=20 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=20 "news" is "something that hardly ever happens." -- Bruce Schneier