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@xxxxxxxx >> http://www.saout.de/mailman/listinfo/dm-crypt > _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
