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 -- Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@xxxxxxxxxxx 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 _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt