[dm-crypt] Incidentaly partitioned LUKS device - header lost?

[dm-crypt] Incidentaly partitioned LUKS device - header lost?

[Bernd Brägelmann]

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

Re: [dm-crypt] Incidentaly partitioned LUKS device - header lost?

[Arno Wagner]

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

Re: [dm-crypt] Incidentaly partitioned LUKS device - header lost?

[Arno Wagner]

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

Re: [dm-crypt] Incidentaly partitioned LUKS device - header lost?

[Bernd Brägelmann]

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

Re: [dm-crypt] Incidentaly partitioned LUKS device - header lost?

[Arno Wagner]

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

Re: [dm-crypt] Incidentaly partitioned LUKS device - header lost?

[Bernd Brägelmann]

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
> 

Re: [dm-crypt] Incidentaly partitioned LUKS device - header lost?

[Arno Wagner]

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

Re: [dm-crypt] Incidentaly partitioned LUKS device - header lost?

[Bernd Brägelmann]

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
> 

Re: [dm-crypt] Incidentaly partitioned LUKS device - header lost?

[Arno Wagner]

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

Re: [dm-crypt] Incidentaly partitioned LUKS device - header lost?

[Michael Kjörling]

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)