[dm-crypt] Corrupted luks partition, help needed

[dm-crypt] Corrupted luks partition, help needed

[Panagiotis Malakoudis]

[-- Attachment #1: Type: text/plain, Size: 6484 bytes --]

I have a luks partition which was corrupted by failed disk i/o. Examining
the partition, the first 512 bytes of the LUKS header is correct, then there
is a corruption which I am not really sure how many sectors affected. Giving
the correct key always returns: "No key available with this passphrase.".
Since the first 512 bytes are correct, I guess all key information is
unharmed. Is there a way to decrypt the partition, even loosing some sectors
of data?

Various logs follow:
cryptsetup luksDump /dev/sdd3
LUKS header information for /dev/sdd3

Version:           1
Cipher name:       aes
Cipher mode:       cbc-essiv:sha256
Hash spec:         sha1
Payload offset:    2056
MK bits:           256
MK digest:         8a 87 ad 0e a4 39 ce cd 26 68 a3 e4 59 90 1c c9 d7 bc d1
e7
MK salt:           28 b2 e9 f6 dc 6a 15 34 a4 e5 e4 b2 fa de e1 68
                   fd af 95 61 27 29 87 72 c8 f7 8f 9c 0f 61 54 bf
MK iterations:     10
UUID:              ca429424-f599-48f5-8c91-
0a1a724e912f

Key Slot 0: ENABLED
    Iterations:             93533
    Salt:                   45 fb 1e 03 3d 4e 4f c0 81 bd 1f 62 2c 2b e4 2c
                              46 11 57 a6 c3 83 a5 7c 82 de a6 9c 88 a1 70
a4
    Key material offset:    8
    AF stripes:                4000
Key Slot 1: DISABLED
Key Slot 2: DISABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

00000000  4c 55 4b 53 ba be 00 01  61 65 73 00 00 00 00 00
|LUKS....aes.....|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
|................|
00000020  00 00 00 00 00 00 00 00  63 62 63 2d 65 73 73 69
|........cbc-essi|
00000030  76 3a 73 68 61 32 35 36  00 00 00 00 00 00 00 00
|v:sha256........|
00000040  00 00 00 00 00 00 00 00  73 68 61 31 00 00 00 00
|........sha1....|
00000050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
|................|
00000060  00 00 00 00 00 00 00 00  00 00 08 08 00 00 00 20  |...............
|
00000070  8a 87 ad 0e a4 39 ce cd  26 68 a3 e4 59 90 1c c9
|.....9..&h..Y...|
00000080  d7 bc d1 e7 28 b2 e9 f6  dc 6a 15 34 a4 e5 e4 b2
|....(....j.4....|
00000090  fa de e1 68 fd af 95 61  27 29 87 72 c8 f7 8f 9c
|...h...a').r....|
000000a0  0f 61 54 bf 00 00 00 0a  63 61 34 32 39 34 32 34
|.aT.....ca429424|
000000b0  2d 66 35 39 39 2d 34 38  66 35 2d 38 63 39 31 2d
|-f599-48f5-8c91-|
000000c0  30 61 31 61 37 32 34 65  39 31 32 66 00 00 00 00
|0a1a724e912f....|
000000d0  00 ac 71 f3 00 01 6d 5d  45 fb 1e 03 3d 4e 4f c0
|..q...m]E...=NO.|
000000e0  81 bd 1f 62 2c 2b e4 2c  46 11 57 a6 c3 83 a5 7c
|...b,+.,F.W....||
000000f0  82 de a6 9c 88 a1 70 a4  00 00 00 08 00 00 0f a0
|......p.........|
00000100  00 00 de ad 00 00 00 00  00 00 00 00 00 00 00 00
|................|
00000110  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
|................|
00000120  00 00 00 00 00 00 00 00  00 00 01 08 00 00 0f a0
|................|
00000130  00 00 de ad 00 00 00 00  00 00 00 00 00 00 00 00
|................|
00000140  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
|................|
00000150  00 00 00 00 00 00 00 00  00 00 02 08 00 00 0f a0
|................|
00000160  00 00 de ad 00 00 00 00  00 00 00 00 00 00 00 00
|................|
00000170  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
|................|
00000180  00 00 00 00 00 00 00 00  00 00 03 08 00 00 0f a0
|................|
00000190  00 00 de ad 00 00 00 00  00 00 00 00 00 00 00 00
|................|
000001a0  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  00 00 04 08 00 00 0f a0
|................|
000001c0  00 00 de ad 00 00 00 00  00 00 00 00 00 00 00 00
|................|
000001d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
|................|
000001e0  00 00 00 00 00 00 00 00  00 00 05 08 00 00 0f a0
|................|
000001f0  00 00 de ad 00 00 00 00  00 00 00 00 00 00 00 00
|................|
00000200  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
|................|
00000210  00 00 00 00 00 00 00 00  00 00 06 08 00 00 0f a0
|................|
00000220  00 00 de ad 00 00 00 00  00 00 00 00 00 00 00 00
|................|
00000230  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00
|................|
00000240  00 00 00 00 00 00 00 00  00 00 07 08 00 00 0f a0
|................|

this shouldn't be here, so this is where corruption starts!!!!

00000250  13 8e 3c 67 f5 3e 82 c4  12 d4 8f e6 31 9b 84 89
|..<g.>......1...|
00000260  27 79 e1 f5 1a e3 15 5e  94 a1 c3 6e b0 57 33 8e
|'y.....^...n.W3.|
00000270  b0 58 bb 21 f9 c3 10 11  59 d0 28 1e a6 7b f2 ce
|.X.!....Y.(..{..|
00000280  7c b3 2e d6 51 0f 68 d0  df 83 e4 52 3e 3b ad 2f
||...Q.h....R>;./|
00000290  c6 05 8d a5 92 a2 a2 8a  bc c6 4f 22 a4 a6 a9 dc
|..........O"....|
000002a0  3b 1d 41 85 41 7f 5d e9  60 6f f2 e1 b3 a5 99 c3
|;.A.A.].`o......|
000002b0  31 f7 d9 64 cc e6 42 43  ad b7 5f 62 ca fa a8 dd
|1..d..BC.._b....|
000002c0  fd bc 45 8b 2a 98 7d c2  0f 4b 07 a3 1a 08 1b 45
|..E.*.}..K.....E|
000002d0  91 9e 3d fe 24 de 72 91  fe e9 5c 99 c9 d8 0c 71
|..=.$.r...\....q|
000002e0  32 e8 cb df 01 67 4f dc  72 fe a8 d5 57 f2 4c 2b
|2....gO.r...W.L+|
000002f0  46 4a 9c 08 d4 ba 3a 3e  78 7a e6 ca b4 e8 5f a4
|FJ....:>xz...._.|
00000300  61 4f 87 0c 79 e8 dc 13  e9 65 92 ed 9d f4 f7 3c
|aO..y....e.....<|
00000310  9f d6 35 eb 10 7a ab 72  a7 c6 05 91 2e 44 60 f2
|..5..z.r.....D`.|
00000320  9a 0e f2 b1 b2 93 1b ba  49 c6 c4 98 cf 31 ec 28
|........I....1.(|
00000330  27 99 2c 3a 2f 74 6f 95  40 3b a8 1c f8 18 3e 27  |'.,:/to.@
;....>'|
00000340  79 12 ad 79 f6 8f df 58  3d 1a 6c c5 e0 c4 8c f6
|y..y...X=.l.....|
00000350  7b c1 3d e4 9a 34 15 43  39 48 e0 25 e8 e5 53 f2
|{.=..4.C9H.%..S.|
00000360  80 0c a9 7e 45 59 e0 ef  0a 0f d4 f3 03 ce 1a 23
|...~EY.........#|
00000370  e7 72 b9 c2 aa 86 bd ad  c9 f5 f9 cf 54 8e 4a 5d
|.r..........T.J]|
00000380  35 db f0 5f 93 f1 84 10  f9 bc 1f ab 59 49 0b d7
|5.._........YI..|
00000390  30 ca 9f 00 59 7c 49 b2  1d e7 81 ec eb 72 72 2d
|0...Y|I......rr-|
000003a0  ac 05 ca d5 8d 8a 2f 8a  e0 4c f2 1d b6 7d 9e eb
|....../..L...}..|
000003b0  26 d0 c7 ce c0 b0 65 23  2f 63 04 d1 1b 5f 98 8d
|&.....e#/c..._..|
000003c0  02 3a be 57 4f 96 a2 b4  e1 cb e3 83 e5 b4 fc 49
|.:.WO..........I|
000003d0  fe 30 6a e6 2e 19 76 1e  30 28 63 9d e2 83 67 51
|.0j...v.0(c...gQ|
000003e0  29 93 02 1f 3c 81 a5 f7  34 af 03 a6 a5 ed 10 1a
|)...<...4.......|
000003f0  f5 64 f2 5c 75 67 3e 05  e2 9b 60 b2 b6 c3 73 38
|.d.\ug>...`...s8|
00000400

[-- Attachment #2: Type: text/html, Size: 7040 bytes --]

Re: [dm-crypt] Corrupted luks partition, help needed

[Milan Broz]

On 06/03/2010 05:32 PM, Panagiotis Malakoudis wrote:
> I have a luks partition which was corrupted by failed disk i/o.
> Examining the partition, the first 512 bytes of the LUKS header is
> correct, then there is a corruption which I am not really sure how many
> sectors affected. Giving the correct key always returns: "No key
> available with this passphrase.". Since the first 512 bytes are correct,
> I guess all key information is unharmed. Is there a way to decrypt the
> partition, even loosing some sectors of data?

If any part of the used keyslot (which is located after visible header,
- in you case starting at sector 8 to sector 264 (hope I calculated it properly),
is modified or lost, you lost that keyslot completely.

Because you have only one active keyslot, you probably lost the whole disk:-(
(Only backup of this keyslot area can help here.)

Milan

Re: [dm-crypt] Corrupted luks partition, help needed

[Panagiotis Malakoudis]

[-- Attachment #1: Type: text/plain, Size: 1403 bytes --]

Hello Milan and thank you for your answer.

I thought that the information shown in luksDump is enough to use those keys
for decoding. I thought the extra 128KB per keyslot are for checksum
verification, so if they are modified then checksum fails and key is not
selected. However, since I know this is the correct key, is there any way to
force the usage of it even if checksum fails?

Thanks again,

Panagiotis Malakoudis

On Thu, Jun 3, 2010 at 6:51 PM, Milan Broz <mbroz@redhat.com> wrote:

> On 06/03/2010 05:32 PM, Panagiotis Malakoudis wrote:
> > I have a luks partition which was corrupted by failed disk i/o.
> > Examining the partition, the first 512 bytes of the LUKS header is
> > correct, then there is a corruption which I am not really sure how many
> > sectors affected. Giving the correct key always returns: "No key
> > available with this passphrase.". Since the first 512 bytes are correct,
> > I guess all key information is unharmed. Is there a way to decrypt the
> > partition, even loosing some sectors of data?
>
> If any part of the used keyslot (which is located after visible header,
> - in you case starting at sector 8 to sector 264 (hope I calculated it
> properly),
> is modified or lost, you lost that keyslot completely.
>
> Because you have only one active keyslot, you probably lost the whole
> disk:-(
> (Only backup of this keyslot area can help here.)
>
> Milan
>

[-- Attachment #2: Type: text/html, Size: 1809 bytes --]

Re: [dm-crypt] Corrupted luks partition, help needed

[Panagiotis Malakoudis]

[-- Attachment #1: Type: text/plain, Size: 1543 bytes --]

OK, I looked a bit more inside LUKS specification and I now know that the
128KB keyslot is actually the 32byte master key AF-split to 128KB and then
encoded with my key. A single bit of change in these 128KB makes key
invalid.

Now that I know all this, I consider the LUKS format fundamentally flawed to
data corruption. A single bit flip invalidates your key. cryptsetup should
point that out this and suggest using at least two keyslots, just for
precaution from data corruption. A second copy of the LUKS header would also
be of great help here.

Fatality ...

On Thu, Jun 3, 2010 at 6:51 PM, Milan Broz <mbroz@redhat.com> wrote:

> On 06/03/2010 05:32 PM, Panagiotis Malakoudis wrote:
> > I have a luks partition which was corrupted by failed disk i/o.
> > Examining the partition, the first 512 bytes of the LUKS header is
> > correct, then there is a corruption which I am not really sure how many
> > sectors affected. Giving the correct key always returns: "No key
> > available with this passphrase.". Since the first 512 bytes are correct,
> > I guess all key information is unharmed. Is there a way to decrypt the
> > partition, even loosing some sectors of data?
>
> If any part of the used keyslot (which is located after visible header,
> - in you case starting at sector 8 to sector 264 (hope I calculated it
> properly),
> is modified or lost, you lost that keyslot completely.
>
> Because you have only one active keyslot, you probably lost the whole
> disk:-(
> (Only backup of this keyslot area can help here.)
>
> Milan
>

[-- Attachment #2: Type: text/html, Size: 1945 bytes --]

Re: [dm-crypt] Corrupted luks partition, help needed

[Milan Broz]

On 06/03/2010 06:16 PM, Panagiotis Malakoudis wrote:
> Hello Milan and thank you for your answer.
> 
> I thought that the information shown in luksDump is enough to use those
> keys for decoding. I thought the extra 128KB per keyslot are for
> checksum verification, so if they are modified then checksum fails and
> key is not selected. However, since I know this is the correct key, is
> there any way to force the usage of it even if checksum fails?

The key, you are entering to cryptsetup, is just "passphrase" to unlock keyslot.
Simplified - after decryption and iterated hashing of the keyslot
area you get the master (volume) key which is used in disk encryption.
(that volume key is generated during luksFormat, it is not derived
from passphrase in LUKS)

Data contained in luksDump is just master key fingerprint + keyslot
attributes, used to verify the correct key fingerprint.

Btw format is now flawed - see antiforensic split function. It is designed
that even if hw internally relocates part of keyslot area (so you cannot wipe it),
it is not possible reconstruct master key with some old passphrase knowledge
and these relocated sectors content. 

And also see luksHeaderBackup and restore command.

Milan

Re: [dm-crypt] Corrupted luks partition, help needed

[Arno Wagner]

On Thu, Jun 03, 2010 at 09:05:59PM +0300, Panagiotis Malakoudis wrote:
> OK, I looked a bit more inside LUKS specification and I now know that the
> 128KB keyslot is actually the 32byte master key AF-split to 128KB and then
> encoded with my key. A single bit of change in these 128KB makes key
> invalid.
> 
> Now that I know all this, I consider the LUKS format fundamentally flawed to
> data corruption. 

It is. However this area should not be written by anything except
cryoptsetup. If you look closely basically every filesystem
and partition scheme is about as vulnerable. The thing is,
modern disks do not suffer single bit corruption easily. More
likely are whole lost sectors. 

> A single bit flip invalidates your key. cryptsetup should
> point that out this and suggest using at least two keyslots, just for
> precaution from data corruption. A second copy of the LUKS header 
> would also be of great help here.

The header backup is needed anyways. The anti-forensic property
is a treade-off between vulnerability to corruption and 
security. Using two keyslots will not help because
if you get your full-sector corruption (and that is what you
get in allmost all cases) in the header, everything is gone 
as well, because there is no way to reconstruct the salts.

So header+keyslot backyp is advisable in some cases, but it
decreases your security, for example old and invalidated
keyslots can be made to work again with such a backup.

It is not that simple and depends on the use case. I can 
understand your frustration though.

Arno 


 
> Fatality ...
> 
> On Thu, Jun 3, 2010 at 6:51 PM, Milan Broz <mbroz@redhat.com> wrote:
> 
> > On 06/03/2010 05:32 PM, Panagiotis Malakoudis wrote:
> > > I have a luks partition which was corrupted by failed disk i/o.
> > > Examining the partition, the first 512 bytes of the LUKS header is
> > > correct, then there is a corruption which I am not really sure how many
> > > sectors affected. Giving the correct key always returns: "No key
> > > available with this passphrase.". Since the first 512 bytes are correct,
> > > I guess all key information is unharmed. Is there a way to decrypt the
> > > partition, even loosing some sectors of data?
> >
> > If any part of the used keyslot (which is located after visible header,
> > - in you case starting at sector 8 to sector 264 (hope I calculated it
> > properly),
> > is modified or lost, you lost that keyslot completely.
> >
> > Because you have only one active keyslot, you probably lost the whole
> > disk:-(
> > (Only backup of this keyslot area can help here.)
> >
> > Milan
> >

> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt


-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

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] Corrupted luks partition, help needed

[Luca Berra]

On Thu, Jun 03, 2010 at 10:14:53PM +0200, Arno Wagner wrote:
>On Thu, Jun 03, 2010 at 09:05:59PM +0300, Panagiotis Malakoudis wrote:
>> OK, I looked a bit more inside LUKS specification and I now know that the
>> 128KB keyslot is actually the 32byte master key AF-split to 128KB and then
>> encoded with my key. A single bit of change in these 128KB makes key
>> invalid.
>> 
>> Now that I know all this, I consider the LUKS format fundamentally flawed to
>> data corruption. 
>
>It is. However this area should not be written by anything except
>cryoptsetup. If you look closely basically every filesystem
>and partition scheme is about as vulnerable. The thing is,
>modern disks do not suffer single bit corruption easily. More
>likely are whole lost sectors. 

well, actually if you look closely at modern filesystems and
partitioning schemes, you will find there are more than one copy of
critical metadata.
ext2 has a backup superblock 
GPT partition has a secondary header and table at the other end of the
disk

we really miss an on-disk backup of the LUKS header.

L.

-- 
Luca Berra -- bluca@comedia.it
         Communication Media & Services S.r.l.
  /"\
  \ /     ASCII RIBBON CAMPAIGN
   X        AGAINST HTML MAIL
  / \

Re: [dm-crypt] Corrupted luks partition, help needed

[Christoph Anton Mitterer]

[-- Attachment #1: Type: text/plain, Size: 703 bytes --]

On Thu, 2010-06-03 at 22:48 +0200, Luca Berra wrote:
> well, actually if you look closely at modern filesystems and
> partitioning schemes, you will find there are more than one copy of
> critical metadata.
> ext2 has a backup superblock 
> GPT partition has a secondary header and table at the other end of the
> disk
> 
> we really miss an on-disk backup of the LUKS header.
It's never a good idea to spread such security critical information like
the master key to much.
Therefore the current design of having only one copy per volume is the
right design.

Everybody can easily make backups of the header, and store them e.g.
heavily encrypted at a secure place.


Cheers,
Chris.

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3387 bytes --]

Re: [dm-crypt] Corrupted luks partition, help needed

[Arno Wagner]

On Thu, Jun 03, 2010 at 10:48:18PM +0200, Luca Berra wrote:
> On Thu, Jun 03, 2010 at 10:14:53PM +0200, Arno Wagner wrote:
>> On Thu, Jun 03, 2010 at 09:05:59PM +0300, Panagiotis Malakoudis wrote:
>>> OK, I looked a bit more inside LUKS specification and I now know that the
>>> 128KB keyslot is actually the 32byte master key AF-split to 128KB and then
>>> encoded with my key. A single bit of change in these 128KB makes key
>>> invalid.
>>>
>>> Now that I know all this, I consider the LUKS format fundamentally flawed to
>>> data corruption. 
>>
>> It is. However this area should not be written by anything except
>> cryoptsetup. If you look closely basically every filesystem
>> and partition scheme is about as vulnerable. The thing is,
>> modern disks do not suffer single bit corruption easily. More
>> likely are whole lost sectors. 
>
> well, actually if you look closely at modern filesystems and
> partitioning schemes, you will find there are more than one copy of
> critical metadata.
> ext2 has a backup superblock GPT partition has a secondary header and 
> table at the other end of the
> disk
>
> we really miss an on-disk backup of the LUKS header.

However the partition table does not have a backup at all.

It is a trade-off. Security-wise, an on-disk backup is a risk.
Makeing a backup manually is not that hard. Maybe a function
on cryptsetup or a contributed script could make it easier,
but that is about it. If you do, on the other hand, a
sector-wise backup of the encrypted partition, you not only
get the LUKS header, but also protect all the data against
a disk failure. Keeping in mind that disk failure roughly
has 5% annual probability per disk, that backup is
non-optional in the first place....

Arno
-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

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] Corrupted luks partition, help needed

[Panagiotis Malakoudis]

[-- Attachment #1: Type: text/plain, Size: 3677 bytes --]

A single bit flip can happen, especially in USB keys (I had the corruption
in such a key). It can also happen to disks, by faulty hardware controllers,
overclocked buses etc. The point here is that a single bit flip invalidates
all your data. A sector corruption in the partition table does indeed
invalidate your data, but it is really easy to reconstruct it. A corruption
in the raid superblock also invalidates your data, but this can also be
reconstructed (not really easy, but it can be done). But a corruption in the
LUKS header cannot be undone. Of course, everyone should backup critical
data, residing in encrypted disks or not, however, loosing all your data
just because you lost one sector of the storage device is something that
should be somehow not allowed to happen.

I can suggest two things. A second copy of the first part of the LUKS header
(not the keyslots), residing just after the keyslots. And parity information
to keyslot data, in order to avoid the corruption that you loose some bytes
or one sector.

cryptsetup should also state very clearly the risks of not backing up the
LUKS header. I consider myself a very good linux sysadmin but I wasn't
really aware of the single point of failure that the LUKS header is. Now I
am aware.

On Fri, Jun 4, 2010 at 1:07 AM, Arno Wagner <arno@wagner.name> wrote:

> On Thu, Jun 03, 2010 at 10:48:18PM +0200, Luca Berra wrote:
> > On Thu, Jun 03, 2010 at 10:14:53PM +0200, Arno Wagner wrote:
> >> On Thu, Jun 03, 2010 at 09:05:59PM +0300, Panagiotis Malakoudis wrote:
> >>> OK, I looked a bit more inside LUKS specification and I now know that
> the
> >>> 128KB keyslot is actually the 32byte master key AF-split to 128KB and
> then
> >>> encoded with my key. A single bit of change in these 128KB makes key
> >>> invalid.
> >>>
> >>> Now that I know all this, I consider the LUKS format fundamentally
> flawed to
> >>> data corruption.
> >>
> >> It is. However this area should not be written by anything except
> >> cryoptsetup. If you look closely basically every filesystem
> >> and partition scheme is about as vulnerable. The thing is,
> >> modern disks do not suffer single bit corruption easily. More
> >> likely are whole lost sectors.
> >
> > well, actually if you look closely at modern filesystems and
> > partitioning schemes, you will find there are more than one copy of
> > critical metadata.
> > ext2 has a backup superblock GPT partition has a secondary header and
> > table at the other end of the
> > disk
> >
> > we really miss an on-disk backup of the LUKS header.
>
> However the partition table does not have a backup at all.
>
> It is a trade-off. Security-wise, an on-disk backup is a risk.
> Makeing a backup manually is not that hard. Maybe a function
> on cryptsetup or a contributed script could make it easier,
> but that is about it. If you do, on the other hand, a
> sector-wise backup of the encrypted partition, you not only
> get the LUKS header, but also protect all the data against
> a disk failure. Keeping in mind that disk failure roughly
> has 5% annual probability per disk, that backup is
> non-optional in the first place....
>
> Arno
> --
> Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email:
> arno@wagner.name
> GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25
> 338F
> ----
> Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans
>
> 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
>

[-- Attachment #2: Type: text/html, Size: 4537 bytes --]

Re: [dm-crypt] Corrupted luks partition, help needed

[Roscoe]

I'm with Chris. Make backups of the header if it concerns you.

On Fri, Jun 4, 2010 at 4:05 PM, Panagiotis Malakoudis
<malakudi@gmail.com> wrote:
> A single bit flip can happen, especially in USB keys (I had the corruption
> in such a key). It can also happen to disks, by faulty hardware controllers,
> overclocked buses etc. The point here is that a single bit flip invalidates
> all your data. A sector corruption in the partition table does indeed
> invalidate your data, but it is really easy to reconstruct it. A corruption
> in the raid superblock also invalidates your data, but this can also be
> reconstructed (not really easy, but it can be done). But a corruption in the
> LUKS header cannot be undone. Of course, everyone should backup critical
> data, residing in encrypted disks or not, however, loosing all your data
> just because you lost one sector of the storage device is something that
> should be somehow not allowed to happen.

For what it's worth if it is really a single bit flip, for an n-bit
string you only have to try n possibilities. So you have
256*4000=1024000 possibilities to go through. Amazon will give us a
EC2 VM with "20" compute units which is about 20x a reference 1.2GHz
Opteron for $0.68/hour.
I wouldn't be surprised if my current 1.4GHz Atom was slower, and it
takes around 5 seconds to unlock a keyslot.

So, we'll need around (5 * 1024000) / 20 / 3600 * 0.68 = $50 and an
EC2 account to retrieve one of my keyslots :).

> I can suggest two things. A second copy of the first part of the LUKS header
> (not the keyslots), residing just after the keyslots. And parity information
> to keyslot data, in order to avoid the corruption that you loose some bytes
> or one sector.

Seems we're undoing the work of the AF splitter.

-- Roscoe

[dm-crypt] cryptsetup administration tool

[Ali Reza Sajedi]

Hello All,

Does anyone know if there is a cryptsetup administration tool written in 
PERL.

Any hint would be greatly appriciated.

Best regards

Ali