[dm-crypt] yet another header reconstruction question

[dm-crypt] yet another header reconstruction question

[Florian Dotzer]

sent again as text. sorry for HTML input. hopefully it is more readable now . 

Dear Readers of the List .
 
I had a encrypted RAID 5 on my QNAP Device  in /dev/md0.
 
It worked without any problems for about 6 years . 
But space went low and desaster began.
After adding a disk , mdadm had overwritten the 
header (block device /dev/md0 ) like this :
 
6d 64 61 64 6d 3a 20 61 64 64 65 64 20 2f 64 65  mdadm: added /de
76 2f 73 64 63 33 0a 00 00 00 00 00 00 00 00 00  v/sdc3..........
00 00 00 00 00 00 00 00 63 62 63 2d 70 6c 61 69  ........cbc-plai
6e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  n...............
00 00 00 00 00 00 00 00 73 68 61 31 00 00 00 00  ........sha1....
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00 00 00 00 00 00 00 00 00 00 08 08 00 00 00 20  ...............
bc 31 80 6d da a4 f0 5c ed 9f 24 96 fc 1b 72 6a
 
According to the documentation on-disk-format ,
magic (LUKS 0xba 0xbe )  , version and cipher name 
seem to be overwritten.
 
I'd like to know the possible versions ( 00 01 ? ) and cipher names 
(aes ?) in order to be able to reconstruct the header (fingers crossed )
 
user support from vendor QNAP tried an hour claiming 
'fs super block could not be found'
and finally redirected me to 'commercial $$$upport' . 
 
QNAP advertised my Box with 
'Disks can be AES-encrypted with 256 bit " so
I suspect its something related with aes .
 
(And no , I had no header backup, Ahhh !)
 
Any helpful reply is welcome . 
And yes , I will make backups in the future . ;-))
 
Greetings , Florian

Re: [dm-crypt] yet another header reconstruction question

[Michael Kjörling]

On 16 Feb 2016 12:32 +0100, from florian.dotzer@web.de (Florian Dotzer):
> I had a encrypted RAID 5 on my QNAP Device  in /dev/md0.

Insufficient data for meaningful answer.


> It worked without any problems for about 6 years . 
> But space went low and desaster began.
> After adding a disk , mdadm had overwritten the 
> header (block device /dev/md0 ) like this :

What was the exact device layout? Physical storage then MD RAID then
LUKS then some file system, or physical storage then LUKS then MD RAID
then some file system, or some other arrangement?

What was the exact command used to "add a disk"?

-- 
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)

Re: [dm-crypt] yet another header reconstruction question

[Arno Wagner]

On Tue, Feb 16, 2016 at 12:32:06 CET, Florian Dotzer wrote:
> sent again as text. sorry for HTML input. hopefully it is more readable now . 

fine now.
 
> Dear Readers of the List .
>  
> I had a encrypted RAID 5 on my QNAP Device  in /dev/md0.
>  
> It worked without any problems for about 6 years . 
> But space went low and desaster began.
> After adding a disk , mdadm had overwritten the 
> header (block device /dev/md0 ) like this :
>  
> 6d 64 61 64 6d 3a 20 61 64 64 65 64 20 2f 64 65  mdadm: added /de
> 76 2f 73 64 63 33 0a 00 00 00 00 00 00 00 00 00  v/sdc3..........
> 00 00 00 00 00 00 00 00 63 62 63 2d 70 6c 61 69  ........cbc-plai
> 6e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  n...............
> 00 00 00 00 00 00 00 00 73 68 61 31 00 00 00 00  ........sha1....
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> 00 00 00 00 00 00 00 00 00 00 08 08 00 00 00 20  ...............
> bc 31 80 6d da a4 f0 5c ed 9f 24 96 fc 1b 72 6a

What did you do? 
Did you pipe the output from mdadm into /dev/md0?
If so, there might be a chance to recover this.

> According to the documentation on-disk-format ,
> magic (LUKS 0xba 0xbe )  , version and cipher name 
> seem to be overwritten.
>  
> I'd like to know the possible versions ( 00 01 ? ) and cipher names 
> (aes ?) in order to be able to reconstruct the header (fingers crossed )

First, make that header backup now, if you have not already.

The data that is missing depends on the QNAP device. 
Defaults can be changed on compile. Easiest option is 
likely to make a new LUKS container on it and try what 
is in there. You should be able to use the loop-device
procedure from FAQ Item 2.6 from the commandline for 
that. If those values do not work, next option is to
have the QNAP create a LUKS container on a new disk
and see what it does.
  
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] yet another header reconstruction question

[Sven Eschenberg]

Am 16.02.2016 um 16:01 schrieb Arno Wagner:
> On Tue, Feb 16, 2016 at 12:32:06 CET, Florian Dotzer wrote:
>> sent again as text. sorry for HTML input. hopefully it is more readable now .
>
> fine now.
>
>> Dear Readers of the List .
>>
>> I had a encrypted RAID 5 on my QNAP Device  in /dev/md0.
>>
>> It worked without any problems for about 6 years .
>> But space went low and desaster began.
>> After adding a disk , mdadm had overwritten the
>> header (block device /dev/md0 ) like this :
>>
>> 6d 64 61 64 6d 3a 20 61 64 64 65 64 20 2f 64 65  mdadm: added /de
>> 76 2f 73 64 63 33 0a 00 00 00 00 00 00 00 00 00  v/sdc3..........
>> 00 00 00 00 00 00 00 00 63 62 63 2d 70 6c 61 69  ........cbc-plai
>> 6e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  n...............
>> 00 00 00 00 00 00 00 00 73 68 61 31 00 00 00 00  ........sha1....
>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>> 00 00 00 00 00 00 00 00 00 00 08 08 00 00 00 20  ...............
>> bc 31 80 6d da a4 f0 5c ed 9f 24 96 fc 1b 72 6a
>
> What did you do?
> Did you pipe the output from mdadm into /dev/md0?
> If so, there might be a chance to recover this.

Looks alot like he did (if he did it himself manually). If so, maybe he 
can also provide the actual command from the shell history? It could 
help analyzing what happened.

btw: I agree, if just the short output of mdadm was written to the disk 
chances are quite good for recovery.

>
>> According to the documentation on-disk-format ,
>> magic (LUKS 0xba 0xbe )  , version and cipher name
>> seem to be overwritten.
>>
>> I'd like to know the possible versions ( 00 01 ? ) and cipher names
>> (aes ?) in order to be able to reconstruct the header (fingers crossed )
>
> First, make that header backup now, if you have not already.
>
> The data that is missing depends on the QNAP device.
> Defaults can be changed on compile. Easiest option is
> likely to make a new LUKS container on it and try what
> is in there. You should be able to use the loop-device
> procedure from FAQ Item 2.6 from the commandline for
> that. If those values do not work, next option is to
> have the QNAP create a LUKS container on a new disk
> and see what it does.
>
> Regards,
> Arno
>

Regards

-Sven

Re: [dm-crypt] yet another header reconstruction question

[Arno Wagner]

Excellent. Also, thank you for the feedback!

Regards,
Arno



On Wed, Feb 24, 2016 at 09:43:02 CET, Florian Dotzer wrote:
> 
>  
> On 02/18/2016 02:51 AM, Florian Dotzer wrote:
> >> I tried dd on files to replace the first 512 bytes of a file , but
> >> the target file was completely replaced with this command :
> >>
> >> dd if=512_bytes_with_fixed_header of=file_with_first_64_MB_of_md0 bs=512 count=1
> 
> > When the target is a file, you need to include "conv=notrunc" so
> > that the file will not be truncated to zero length when it is
> > opened. That is not an issue when the target is a block device,
> > but there is no harm in using "conv=notrunc" there, too.
> 
> Thanks to Bob , Arno , Sven and all others. I was able to remount
> with the corrected LUKS Header . 
> 
> Now I have a backup of the header and a backup of the key. 
> 
> currently I am backing  up all data 
> 
> Please enjoy a virtual drink of your choice ;-)) 
> 
> 
> Sorry  lsblk command was not available so I cannot report any output of that. 
> 
> best wishes to all , Florian
> _______________________________________________
> 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] yet another header reconstruction question

[Florian Dotzer]

 
On 02/18/2016 02:51 AM, Florian Dotzer wrote:
>> I tried dd on files to replace the first 512 bytes of a file , but
>> the target file was completely replaced with this command :
>>
>> dd if=512_bytes_with_fixed_header of=file_with_first_64_MB_of_md0 bs=512 count=1

> When the target is a file, you need to include "conv=notrunc" so
> that the file will not be truncated to zero length when it is
> opened. That is not an issue when the target is a block device,
> but there is no harm in using "conv=notrunc" there, too.

Thanks to Bob , Arno , Sven and all others. I was able to remount
with the corrected LUKS Header . 

Now I have a backup of the header and a backup of the key. 

currently I am backing  up all data 

Please enjoy a virtual drink of your choice ;-)) 


Sorry  lsblk command was not available so I cannot report any output of that. 

best wishes to all , Florian

Re: [dm-crypt] yet another header reconstruction question

[Robert Nichols]

On 02/18/2016 02:51 AM, Florian Dotzer wrote:
> I tried dd on files to replace the first 512 bytes of a file , but
> the target file was completely replaced with this command :
>
> dd if=512_bytes_with_fixed_header of=file_with_first_64_MB_of_md0 bs=512 count=1

When the target is a file, you need to include "conv=notrunc" so
that the file  will not be truncated to zero length when it is
opened.  That is not an issue when the target is a block device,
but there is no harm in using "conv=notrunc" there, too.

-- 
Bob Nichols     "NOSPAM" is really part of my email address.
                 Do NOT delete it.

Re: [dm-crypt] yet another header reconstruction question

[Sven Eschenberg]

Florian,

While at it (resending in plain text) make sure to include the output of 
lsblk if possible. This should give us an idea of the layout as 
currently being used.

Regards

-Sven


Am 18.02.2016 um 10:34 schrieb Michael Kjörling:
> On 18 Feb 2016 09:51 +0100, from florian.dotzer@web.de (Florian Dotzer):
>> <html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div><br/>
>
> Please resend as not HTML.
>
>> &nbsp;@Michael , Arno , Sven :<br/>
>> <br/>
>> Thanks for your replies and the help you are offering . Thats real support compared to experience with QNAP support ;-))<br/>
>> I *can* login as root to the QNAP box - but I am not a shell guru .<br/>
>> I hope I will be able to unlock my LUKS Copntainer without losing my Data .<br/>
>> <br/>
>> I used the graphical GUI of QNAP which offered this possibility to add a disk to an existing RAID ,<br/>
>> e.g. I clicked a Button named &quot;Add hard drive&quot; in the RAID Management Section ,<br/>
>> selected the newly added disk, and waited for the desaster to complete<br/>
>> <br/>
>> (german slang : mausi klickibunti ) .<br/>
>> <br/>
>> Somehow the command output was written to the Device and not elsewhere (/dev / null or shell )<br/>
>> <br/>
>> Michael wrote :<br/>
>> &gt; What was the exact device layout?<br/>
>> &gt; Physical storage then MD RAID<br/>
>> Yes. I have the box not at my desk here. Sorry.<br/>
>> <br/>
>> &gt; then LUKS<br/>
>> At least I found a corrupted LUKSHeader there in /dev/md0<br/>
>> <br/>
>> &gt; then some file system,<br/>
>> I hope so , thats where my data lives .<br/>
>> <br/>
>> YESS Sir<br/>
>> <br/>
>> &gt; or physical storage then LUKS then MD RAID<br/>
>> &gt;then some file system, or some other arrangement?<br/>
>> No<br/>
>> <br/>
>> &gt;What was the exact command used to &quot;add a disk&quot;?<br/>
>> QNAP may know it , I not. I didnt find anything in dmesg / kernel log or elsewhere .<br/>
>> <br/>
>>  From the best of my limited knowledge as I interpret the findings when I login as root in the cli ,<br/>
>> I see the RAID created with mdadm as built dirctly on the disk partitions sd[d&#124;e&#124;f&#124;g&#124;h&#124;c]3<br/>
>> <br/>
>> where /dev/sdc is the disk I added .<br/>
>> the raid itself is up with all disks , (all disks &#39;U&#39; ) , valid / valid superblock<br/>
>> I can get and read data from the block device /dev/md0<br/>
>> as you have seen in my last email.<br/>
>> &nbsp;<br/>
>> <br/>
>> <br/>
>> @ Arno :<br/>
>> <br/>
>> &gt; What did you do?<br/>
>> &gt; Did you pipe the output from mdadm into /dev/md0?<br/>
>> No.<br/>
>> &gt; If so, there might be a chance to recover this.<br/>
>> <br/>
>> &gt; First, make that header backup now, if you have not already.<br/>
>> <br/>
>> I have at least the first 64 MB of /dev/md0 extracted with dd if=/dev/md0 of=of=file_with_first_64_MB_of_md0 bs=1024 count=65535<br/>
>> The hex Dump was extracted from this .<br/>
>> I hope that is enough for a header backup (approx. 2MiB + xxx as stated in the FAQ) ?<br/>
>> <br/>
>> &gt; The data that is missing depends on the QNAP device.<br/>
>> SS839 PRO<br/>
>> &gt; Defaults can be changed on compile.<br/>
>> I only have binaries , no sources , no compiler<br/>
>> &gt; Easiest option is<br/>
>> &gt; likely to make a new LUKS container on it and try what<br/>
>> &gt; is in there. You should be able to use the loop-device<br/>
>> &gt; procedure from FAQ Item 2.6 from the commandline for<br/>
>> &gt; that. If those values do not work, next option is to<br/>
>> &gt; have the QNAP create a LUKS container on a new disk<br/>
>> &gt; and see what it does.<br/>
>> <br/>
>> I&#39;ll try it that weekend or next when I have time to do it .<br/>
>> <br/>
>> <br/>
>> @Sven :<br/>
>> <br/>
>> &gt;btw: I agree, if just the short output of mdadm was written to the disk<br/>
>> &gt;chances are quite good for recovery.<br/>
>> <br/>
>> I hope so. I tried dd on files to replace the first 512 bytes of a file , but<br/>
>> the target file was completely replaced with this command :<br/>
>> <br/>
>> dd if=512_bytes_with_fixed_header of=file_with_first_64_MB_of_md0 bs=512 count=1<br/>
>> <br/>
>> Now I dont know if dd&#39;s behaviour is different on block device level ,<br/>
>> or is there another better way to replace / correct the first bytes of /dev/md0 ?<br/>
>> <br/>
>> <br/>
>> Greetings , Florian<br/>
>> &nbsp;</div></div></body></html>
>

Re: [dm-crypt] yet another header reconstruction question

[Michael Kjörling]

On 18 Feb 2016 09:51 +0100, from florian.dotzer@web.de (Florian Dotzer):
> <html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div><br/>

Please resend as not HTML.

> &nbsp;@Michael , Arno , Sven :<br/>
> <br/>
> Thanks for your replies and the help you are offering . Thats real support compared to experience with QNAP support ;-))<br/>
> I *can* login as root to the QNAP box - but I am not a shell guru .<br/>
> I hope I will be able to unlock my LUKS Copntainer without losing my Data .<br/>
> <br/>
> I used the graphical GUI of QNAP which offered this possibility to add a disk to an existing RAID ,<br/>
> e.g. I clicked a Button named &quot;Add hard drive&quot; in the RAID Management Section ,<br/>
> selected the newly added disk, and waited for the desaster to complete<br/>
> <br/>
> (german slang : mausi klickibunti ) .<br/>
> <br/>
> Somehow the command output was written to the Device and not elsewhere (/dev / null or shell )<br/>
> <br/>
> Michael wrote :<br/>
> &gt; What was the exact device layout?<br/>
> &gt; Physical storage then MD RAID<br/>
> Yes. I have the box not at my desk here. Sorry.<br/>
> <br/>
> &gt; then LUKS<br/>
> At least I found a corrupted LUKSHeader there in /dev/md0<br/>
> <br/>
> &gt; then some file system,<br/>
> I hope so , thats where my data lives .<br/>
> <br/>
> YESS Sir<br/>
> <br/>
> &gt; or physical storage then LUKS then MD RAID<br/>
> &gt;then some file system, or some other arrangement?<br/>
> No<br/>
> <br/>
> &gt;What was the exact command used to &quot;add a disk&quot;?<br/>
> QNAP may know it , I not. I didnt find anything in dmesg / kernel log or elsewhere .<br/>
> <br/>
> From the best of my limited knowledge as I interpret the findings when I login as root in the cli ,<br/>
> I see the RAID created with mdadm as built dirctly on the disk partitions sd[d&#124;e&#124;f&#124;g&#124;h&#124;c]3<br/>
> <br/>
> where /dev/sdc is the disk I added .<br/>
> the raid itself is up with all disks , (all disks &#39;U&#39; ) , valid / valid superblock<br/>
> I can get and read data from the block device /dev/md0<br/>
> as you have seen in my last email.<br/>
> &nbsp;<br/>
> <br/>
> <br/>
> @ Arno :<br/>
> <br/>
> &gt; What did you do?<br/>
> &gt; Did you pipe the output from mdadm into /dev/md0?<br/>
> No.<br/>
> &gt; If so, there might be a chance to recover this.<br/>
> <br/>
> &gt; First, make that header backup now, if you have not already.<br/>
> <br/>
> I have at least the first 64 MB of /dev/md0 extracted with dd if=/dev/md0 of=of=file_with_first_64_MB_of_md0 bs=1024 count=65535<br/>
> The hex Dump was extracted from this .<br/>
> I hope that is enough for a header backup (approx. 2MiB + xxx as stated in the FAQ) ?<br/>
> <br/>
> &gt; The data that is missing depends on the QNAP device.<br/>
> SS839 PRO<br/>
> &gt; Defaults can be changed on compile.<br/>
> I only have binaries , no sources , no compiler<br/>
> &gt; Easiest option is<br/>
> &gt; likely to make a new LUKS container on it and try what<br/>
> &gt; is in there. You should be able to use the loop-device<br/>
> &gt; procedure from FAQ Item 2.6 from the commandline for<br/>
> &gt; that. If those values do not work, next option is to<br/>
> &gt; have the QNAP create a LUKS container on a new disk<br/>
> &gt; and see what it does.<br/>
> <br/>
> I&#39;ll try it that weekend or next when I have time to do it .<br/>
> <br/>
> <br/>
> @Sven :<br/>
> <br/>
> &gt;btw: I agree, if just the short output of mdadm was written to the disk<br/>
> &gt;chances are quite good for recovery.<br/>
> <br/>
> I hope so. I tried dd on files to replace the first 512 bytes of a file , but<br/>
> the target file was completely replaced with this command :<br/>
> <br/>
> dd if=512_bytes_with_fixed_header of=file_with_first_64_MB_of_md0 bs=512 count=1<br/>
> <br/>
> Now I dont know if dd&#39;s behaviour is different on block device level ,<br/>
> or is there another better way to replace / correct the first bytes of /dev/md0 ?<br/>
> <br/>
> <br/>
> Greetings , Florian<br/>
> &nbsp;</div></div></body></html>

-- 
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)

Re: [dm-crypt] yet another header reconstruction question

[Florian Dotzer]

[-- Attachment #1: Type: text/html, Size: 3805 bytes --]

Re: [dm-crypt] Yet another header reconstruction question

[Arno Wagner]

Please re-send as non-HTML. Thanks.

Arno

On Mon, Feb 15, 2016 at 17:07:35 CET, Florian Dotzer wrote:
> <html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>Dear Readers of the List .</div>
> 
> <div>&nbsp;</div>
> 
> <div>I had a encrypted RAID 5on my QNAP Device&nbsp; in /dev/md0.</div>
> 
> <div>&nbsp;</div>
> 
> <div>It worked without any problems for about 6 years . But space went low and desaster began.</div>
> 
> <div>After adding a disk , mdadm had overwritten the header (block device /dev/md0 ) like this :</div>
> 
> <div>&nbsp;</div>
> 
> <div><span style="font-family: courier new , courier , monospace;">6d 64 61 64 6d 3a 20 61 64 64 65 64 20 2f 64 65&nbsp; mdadm: added /de</span></div>
> 
> <div><span style="font-family: courier new , courier , monospace;">76 2f 73 64 63 33 0a 00 00 00 00 00 00 00 00 00&nbsp; v/sdc3.......... </span></div>
> 
> <div><span style="font-family: courier new , courier , monospace;">00 00 00 00 00 00 00 00 <strong>63 62 63 2d 70 6c 61 69</strong>&nbsp; ........cbc-plai </span></div>
> 
> <div><span style="font-family: courier new , courier , monospace;"><strong>6e </strong>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00&nbsp; n............... </span></div>
> 
> <div><span style="font-family: courier new , courier , monospace;">00 00 00 00 00 00 00 00 <strong>73 68 61 31</strong> 00 00 00 00&nbsp; ........sha1.... </span></div>
> 
> <div><span style="font-family: courier new , courier , monospace;">00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00&nbsp; ................ </span></div>
> 
> <div><span style="font-family: courier new , courier , monospace;">00 00 00 00 00 00 00 00 00 00 <strong>08 08</strong> 00 00 00 <strong>20</strong>&nbsp; ............... </span></div>
> 
> <div><span style="font-family: courier new , courier , monospace;">bc 31 80 6d da a4 f0 5c ed 9f 24 96 fc 1b 72 6a </span></div>
> 
> <div>&nbsp;</div>
> 
> <div>According to the documentation on-disk-format ,</div>
> 
> <div>magic (LUKS 0xba 0x be )&nbsp; , version and cipher name seem to be overwritten.</div>
> 
> <div>&nbsp;</div>
> 
> <div>I&#39;d like to know the possible versions ( 00 01 ? ) and cipher names&nbsp;</div>
> 
> <div>(aes ?) in order to be able to reconstruct the header (fingers crossed )</div>
> 
> <div>&nbsp;</div>
> 
> <div>user support from vendor QNAP tried an hour claiming &#39;fs super block could not be found&#39;</div>
> 
> <div>and finally redirected me to &#39;commercial &#36;&#36;&#36;upport&#39; .&nbsp;</div>
> 
> <div>&nbsp;</div>
> 
> <div>QNAP advertised my Box with &#39;Disks can be AES-encrypted with 256 bit &quot; so</div>
> 
> <div>I suspect its something related with aes .</div>
> 
> <div>&nbsp;</div>
> 
> <div>(And no , I had no header backup, Ahhh !)</div>
> 
> <div>&nbsp;</div>
> 
> <div>Any helpful reply is welcome . And yes , I will make backups in the future . ;-))</div>
> 
> <div>&nbsp;</div>
> 
> <div>Greetings , Florian</div></div></body></html>

> _______________________________________________
> 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] Yet another header reconstruction question

[Florian Dotzer]

[-- Attachment #1: Type: text/html, Size: 2748 bytes --]