* [dm-crypt] Incidentaly partitioned LUKS device - header lost? @ 2016-07-02 6:33 Bernd Brägelmann 2016-07-02 10:20 ` Arno Wagner 0 siblings, 1 reply; 10+ messages in thread From: Bernd Brägelmann @ 2016-07-02 6:33 UTC (permalink / raw) To: dm-crypt Hi there, i think i destroyed my luks data. I accidentally created a msdos partition table on the luks device. I think the device was not partitioned. The device is a raid5 mdadm at /dev/md2. Now i cannot luksOpen the device anymore. I already try to hexdump|grep for the LUKS header but until now i haven't found it. In the Luks-FAQ 6.1 the problem is described as a common user error and it is very common that the partitioning has destroyed the LUKS header. My question is: Is my data destroyed beyond recovery? It would really help me to cope with this. Is it possible to "manually" fix a partially destroyed LUKS header? Are there other ways to recover the data? I would gladly pay for a recovery solution. Regards, Bernd -- Bernd Brägelmann - FA für Radiologie Robert-Koch-Straße 42 28277 Bremen www.berndbraegelmann.de +4915141457796 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [dm-crypt] Incidentaly partitioned LUKS device - header lost? 2016-07-02 6:33 [dm-crypt] Incidentaly partitioned LUKS device - header lost? Bernd Brägelmann @ 2016-07-02 10:20 ` Arno Wagner 2016-07-02 10:25 ` Arno Wagner 0 siblings, 1 reply; 10+ messages in thread From: Arno Wagner @ 2016-07-02 10:20 UTC (permalink / raw) To: dm-crypt Hi Bernd, data-recovery for this is typically relatively easy or completely impossible. To determine which it is, we need to find out what happened exactly. The only really irreplaceable values in the header are the salts (see FAQ Item 6.12). These are not secret, but each is 256 bits of crypto-grade randomness and they cannot be reconstructed or guessed. The first question is what was overwritten by that partition sector. Traditionally, Linux software RAID has the RAID superblock at the end, but unfortunately some people "improved" this, so it can now be at the end, at the start and at 4kB from the start. This is relevant becauese it influences the data offset, i.e. the place where the LUKS header is put. Hence we need the output of mdadm --detail /dev/md2 whichs dumps the RAID metadata. Regards, Arno On Sat, Jul 02, 2016 at 08:33:09 CEST, Bernd Brägelmann wrote: > Hi there, > > i think i destroyed my luks data. > > I accidentally created a msdos partition table on the luks device. I > think the device was not partitioned. The device is a raid5 mdadm at > /dev/md2. > > Now i cannot luksOpen the device anymore. > > I already try to hexdump|grep for the LUKS header but until now i > haven't found it. In the Luks-FAQ 6.1 the problem is described as a > common user error and it is very common that the partitioning has > destroyed the LUKS header. > > My question is: Is my data destroyed beyond recovery? It would really > help me to cope with this. Is it possible to "manually" fix a partially > destroyed LUKS header? Are there other ways to recover the data? I would > gladly pay for a recovery solution. > > Regards, > > Bernd > > -- > Bernd Brägelmann - FA für Radiologie > Robert-Koch-Straße 42 28277 Bremen > www.berndbraegelmann.de +4915141457796 > _______________________________________________ > dm-crypt mailing list > dm-crypt@saout.de > http://www.saout.de/mailman/listinfo/dm-crypt -- 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 "news" is "something that hardly ever happens." -- Bruce Schneier ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [dm-crypt] Incidentaly partitioned LUKS device - header lost? 2016-07-02 10:20 ` Arno Wagner @ 2016-07-02 10:25 ` Arno Wagner 2016-07-02 10:42 ` Bernd Brägelmann 0 siblings, 1 reply; 10+ messages in thread From: Arno Wagner @ 2016-07-02 10:25 UTC (permalink / raw) To: dm-crypt Ah, sorry, I am confused. The first question is whether you killed the RAID as well or whether you created the msdos partition table within /dev/md2. In the latter case we do not need the RAID info. Regards, Arno On Sat, Jul 02, 2016 at 12:20:00 CEST, Arno Wagner wrote: > Hi Bernd, > > data-recovery for this is typically relatively easy or completely > impossible. To determine which it is, we need to find out what > happened exactly. The only really irreplaceable values in the header > are the salts (see FAQ Item 6.12). These are not secret, but > each is 256 bits of crypto-grade randomness and they cannot > be reconstructed or guessed. > > The first question is what was overwritten by that partition > sector. Traditionally, Linux software RAID has the RAID superblock > at the end, but unfortunately some people "improved" this, so > it can now be at the end, at the start and at 4kB from the start. > > This is relevant becauese it influences the data offset, i.e. > the place where the LUKS header is put. > > Hence we need the output of > > mdadm --detail /dev/md2 > > whichs dumps the RAID metadata. > > Regards, > Arno > > > On Sat, Jul 02, 2016 at 08:33:09 CEST, Bernd Brägelmann wrote: > > Hi there, > > > > i think i destroyed my luks data. > > > > I accidentally created a msdos partition table on the luks device. I > > think the device was not partitioned. The device is a raid5 mdadm at > > /dev/md2. > > > > Now i cannot luksOpen the device anymore. > > > > I already try to hexdump|grep for the LUKS header but until now i > > haven't found it. In the Luks-FAQ 6.1 the problem is described as a > > common user error and it is very common that the partitioning has > > destroyed the LUKS header. > > > > My question is: Is my data destroyed beyond recovery? It would really > > help me to cope with this. Is it possible to "manually" fix a partially > > destroyed LUKS header? Are there other ways to recover the data? I would > > gladly pay for a recovery solution. > > > > Regards, > > > > Bernd > > > > -- > > Bernd Brägelmann - FA für Radiologie > > Robert-Koch-Straße 42 28277 Bremen > > www.berndbraegelmann.de +4915141457796 > > _______________________________________________ > > dm-crypt mailing list > > dm-crypt@saout.de > > http://www.saout.de/mailman/listinfo/dm-crypt > > -- > 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 > "news" is "something that hardly ever happens." -- Bruce Schneier > _______________________________________________ > dm-crypt mailing list > dm-crypt@saout.de > http://www.saout.de/mailman/listinfo/dm-crypt -- 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 "news" is "something that hardly ever happens." -- Bruce Schneier ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [dm-crypt] Incidentaly partitioned LUKS device - header lost? 2016-07-02 10:25 ` Arno Wagner @ 2016-07-02 10:42 ` Bernd Brägelmann 2016-07-02 16:14 ` Arno Wagner 2016-07-03 20:40 ` Michael Kjörling 0 siblings, 2 replies; 10+ messages in thread From: Bernd Brägelmann @ 2016-07-02 10:42 UTC (permalink / raw) To: dm-crypt Hi Arno, thanks for answering. I created the partition table within /dev/md2 and the raid is still working. My current last hope is that the salt might be in a redundant part of the raid array. Currently I grep the single devices for the LUKS-header file like this: grep -a -b -P --only-matching 'LUKS\xba\xbe' /dev/sdc grep -a -b -P --only-matching 'LUKS\xba\xbe' /dev/sdb grep -a -b -P --only-matching 'LUKS\xba\xbe' /dev/sdd Could that be successful? However here is also my mdadm --detail: /dev/md2: Version : 1.2 Creation Time : Thu Jan 3 21:43:32 2013 Raid Level : raid5 Array Size : 3906763776 (3725.78 GiB 4000.53 GB) Used Dev Size : 1953381888 (1862.89 GiB 2000.26 GB) Raid Devices : 3 Total Devices : 3 Persistence : Superblock is persistent Update Time : Fri Jul 1 13:02:14 2016 State : clean Active Devices : 3 Working Devices : 3 Failed Devices : 0 Spare Devices : 0 Layout : left-symmetric Chunk Size : 512K Name : braegel1:2 (local to host braegel1) UUID : 54ee60b5:45837e78:661fa3ed:3eacb88f Events : 44120 Number Major Minor RaidDevice State 0 8 17 0 active sync /dev/sdb1 1 8 33 1 active sync /dev/sdc1 3 8 49 2 active sync /dev/sdd1 Regards, Bernd Am 2. Juli 2016 12:25:17 MESZ, schrieb Arno Wagner <arno@wagner.name>: >Ah, sorry, I am confused. The first question is whether >you killed the RAID as well or whether you created the >msdos partition table within /dev/md2. In the latter >case we do not need the RAID info. > >Regards, >Arno > >On Sat, Jul 02, 2016 at 12:20:00 CEST, Arno Wagner wrote: >> Hi Bernd, >> >> data-recovery for this is typically relatively easy or completely >> impossible. To determine which it is, we need to find out what >> happened exactly. The only really irreplaceable values in the header >> are the salts (see FAQ Item 6.12). These are not secret, but >> each is 256 bits of crypto-grade randomness and they cannot >> be reconstructed or guessed. >> >> The first question is what was overwritten by that partition >> sector. Traditionally, Linux software RAID has the RAID superblock >> at the end, but unfortunately some people "improved" this, so >> it can now be at the end, at the start and at 4kB from the start. >> >> This is relevant becauese it influences the data offset, i.e. >> the place where the LUKS header is put. >> >> Hence we need the output of >> >> mdadm --detail /dev/md2 >> >> whichs dumps the RAID metadata. >> >> Regards, >> Arno >> >> >> On Sat, Jul 02, 2016 at 08:33:09 CEST, Bernd Brägelmann wrote: >> > Hi there, >> > >> > i think i destroyed my luks data. >> > >> > I accidentally created a msdos partition table on the luks device. >I >> > think the device was not partitioned. The device is a raid5 mdadm >at >> > /dev/md2. >> > >> > Now i cannot luksOpen the device anymore. >> > >> > I already try to hexdump|grep for the LUKS header but until now i >> > haven't found it. In the Luks-FAQ 6.1 the problem is described as a >> > common user error and it is very common that the partitioning has >> > destroyed the LUKS header. >> > >> > My question is: Is my data destroyed beyond recovery? It would >really >> > help me to cope with this. Is it possible to "manually" fix a >partially >> > destroyed LUKS header? Are there other ways to recover the data? I >would >> > gladly pay for a recovery solution. >> > >> > Regards, >> > >> > Bernd >> > >> > -- >> > Bernd Brägelmann - FA für Radiologie >> > Robert-Koch-Straße 42 28277 Bremen >> > www.berndbraegelmann.de +4915141457796 >> > _______________________________________________ >> > dm-crypt mailing list >> > dm-crypt@saout.de >> > http://www.saout.de/mailman/listinfo/dm-crypt >> >> -- >> 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 >> "news" is "something that hardly ever happens." -- Bruce Schneier >> _______________________________________________ >> dm-crypt mailing list >> dm-crypt@saout.de >> http://www.saout.de/mailman/listinfo/dm-crypt > >-- >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 >"news" is "something that hardly ever happens." -- Bruce Schneier >_______________________________________________ >dm-crypt mailing list >dm-crypt@saout.de >http://www.saout.de/mailman/listinfo/dm-crypt ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [dm-crypt] Incidentaly partitioned LUKS device - header lost? 2016-07-02 10:42 ` Bernd Brägelmann @ 2016-07-02 16:14 ` Arno Wagner 2016-07-02 18:11 ` Bernd Brägelmann 2016-07-03 20:40 ` Michael Kjörling 1 sibling, 1 reply; 10+ messages in thread From: Arno Wagner @ 2016-07-02 16:14 UTC (permalink / raw) To: dm-crypt 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 -- 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 "news" is "something that hardly ever happens." -- Bruce Schneier ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [dm-crypt] Incidentaly partitioned LUKS device - header lost? 2016-07-02 16:14 ` Arno Wagner @ 2016-07-02 18:11 ` Bernd Brägelmann 2016-07-02 18:55 ` Arno Wagner 0 siblings, 1 reply; 10+ messages in thread From: Bernd Brägelmann @ 2016-07-02 18:11 UTC (permalink / raw) To: dm-crypt 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 -- 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 > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [dm-crypt] Incidentaly partitioned LUKS device - header lost? 2016-07-02 18:11 ` Bernd Brägelmann @ 2016-07-02 18:55 ` Arno Wagner 2016-07-02 20:06 ` Bernd Brägelmann 0 siblings, 1 reply; 10+ messages in thread From: Arno Wagner @ 2016-07-02 18:55 UTC (permalink / raw) To: dm-crypt 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 -- 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 "news" is "something that hardly ever happens." -- Bruce Schneier ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [dm-crypt] Incidentaly partitioned LUKS device - header lost? 2016-07-02 18:55 ` Arno Wagner @ 2016-07-02 20:06 ` Bernd Brägelmann 2016-07-02 21:53 ` Arno Wagner 0 siblings, 1 reply; 10+ messages in thread From: Bernd Brägelmann @ 2016-07-02 20:06 UTC (permalink / raw) To: dm-crypt 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 > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [dm-crypt] Incidentaly partitioned LUKS device - header lost? 2016-07-02 20:06 ` Bernd Brägelmann @ 2016-07-02 21:53 ` Arno Wagner 0 siblings, 0 replies; 10+ messages in thread From: Arno Wagner @ 2016-07-02 21:53 UTC (permalink / raw) To: dm-crypt Hi Bernd, you are welcome. There are quite a few helpful people on 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ägelmann wrote: > 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 > > > _______________________________________________ > dm-crypt mailing list > dm-crypt@saout.de > http://www.saout.de/mailman/listinfo/dm-crypt -- 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 "news" is "something that hardly ever happens." -- Bruce Schneier ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [dm-crypt] Incidentaly partitioned LUKS device - header lost? 2016-07-02 10:42 ` Bernd Brägelmann 2016-07-02 16:14 ` Arno Wagner @ 2016-07-03 20:40 ` Michael Kjörling 1 sibling, 0 replies; 10+ messages in thread From: Michael Kjörling @ 2016-07-03 20:40 UTC (permalink / raw) To: dm-crypt On 2 Jul 2016 12:42 +0200, from bernd@braegelmann.net (Bernd Brägelmann): > My current last hope is that the salt might be in a redundant part of > the raid array. Unfortunately, as Arno has already described, RAID inconsistencies are really short-lived, so there would be no trace of that data by the time you realized your error, much less by the time grep had a chance to finish executing. And we can probably assume that properly done 256-bit AES-XTS is, for all practical purposes, not breakable at the cryptographic level. Compare <https://security.stackexchange.com/a/6149/2138> which concludes that, with some _very_ optimistic assumptions, including using _all of Earth's resources for a decade_, we _might_ be able to _count_ to 2^138 by 2040 or so. (We'd still not be able to actually _do anything useful_ with that counter, so it'd be a rather pointless exercise.) Bottom line, brute forcing AES in anything resembling realistic time frames is simply not feasible. I like Jörg W Mittag's description of the difference between redundancy (RAID) and backups, which feels applicable here: > If you accidentally overwrite your PhD thesis with garbage, > redundancy ensures that you have multiple copies of garbage, in case > one gets bad. A backup ensures that you can restore your PhD thesis. > > (And an archive ensures that you can retrieve multiple older versions > of your thesis, and a version control system also tells you why you > made a new version in the first place.) The above shamelessly borrowed from <https://serverfault.com/a/3697/58408>. What _would_ have helped in your situation, and I'm noting this in the tiny hopes that it might help someone else avoid a similar catastrophe, is a LUKS header backup or the master key for the container, stored somewhere else. (If you dump the header using luksHeaderBackup, then the copy is still encrypted with your passphrase(s), so this is reasonably safe to store. The master key can be dumped unprotected, which is probably a bad idea in many situations but may be valid in others.) Or, of course, `sudo file -s /dev/md2` or `lsblk /dev/md2` before `fdisk /dev/md2`. -- Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se “People who think they know everything really annoy those of us who know we don’t.” (Bjarne Stroustrup) ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2016-07-03 20:46 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-07-02 6:33 [dm-crypt] Incidentaly partitioned LUKS device - header lost? Bernd Brägelmann 2016-07-02 10:20 ` Arno Wagner 2016-07-02 10:25 ` Arno Wagner 2016-07-02 10:42 ` Bernd Brägelmann 2016-07-02 16:14 ` Arno Wagner 2016-07-02 18:11 ` Bernd Brägelmann 2016-07-02 18:55 ` Arno Wagner 2016-07-02 20:06 ` Bernd Brägelmann 2016-07-02 21:53 ` Arno Wagner 2016-07-03 20:40 ` Michael Kjörling
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.