* [dm-crypt] Corrupted luks partition, help needed
@ 2010-06-03 15:32 Panagiotis Malakoudis
2010-06-03 15:51 ` Milan Broz
0 siblings, 1 reply; 12+ messages in thread
From: Panagiotis Malakoudis @ 2010-06-03 15:32 UTC (permalink / raw)
To: dm-crypt
[-- 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 --]
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [dm-crypt] Corrupted luks partition, help needed 2010-06-03 15:32 [dm-crypt] Corrupted luks partition, help needed Panagiotis Malakoudis @ 2010-06-03 15:51 ` Milan Broz 2010-06-03 16:16 ` Panagiotis Malakoudis 2010-06-03 18:05 ` Panagiotis Malakoudis 0 siblings, 2 replies; 12+ messages in thread From: Milan Broz @ 2010-06-03 15:51 UTC (permalink / raw) To: Panagiotis Malakoudis; +Cc: dm-crypt 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [dm-crypt] Corrupted luks partition, help needed 2010-06-03 15:51 ` Milan Broz @ 2010-06-03 16:16 ` Panagiotis Malakoudis 2010-06-03 18:12 ` Milan Broz 2010-06-03 18:05 ` Panagiotis Malakoudis 1 sibling, 1 reply; 12+ messages in thread From: Panagiotis Malakoudis @ 2010-06-03 16:16 UTC (permalink / raw) To: Milan Broz; +Cc: dm-crypt [-- 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 --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [dm-crypt] Corrupted luks partition, help needed 2010-06-03 16:16 ` Panagiotis Malakoudis @ 2010-06-03 18:12 ` Milan Broz 0 siblings, 0 replies; 12+ messages in thread From: Milan Broz @ 2010-06-03 18:12 UTC (permalink / raw) To: Panagiotis Malakoudis; +Cc: dm-crypt 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [dm-crypt] Corrupted luks partition, help needed 2010-06-03 15:51 ` Milan Broz 2010-06-03 16:16 ` Panagiotis Malakoudis @ 2010-06-03 18:05 ` Panagiotis Malakoudis 2010-06-03 20:14 ` Arno Wagner 1 sibling, 1 reply; 12+ messages in thread From: Panagiotis Malakoudis @ 2010-06-03 18:05 UTC (permalink / raw) To: Milan Broz; +Cc: dm-crypt [-- 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 --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [dm-crypt] Corrupted luks partition, help needed 2010-06-03 18:05 ` Panagiotis Malakoudis @ 2010-06-03 20:14 ` Arno Wagner 2010-06-03 20:48 ` Luca Berra 0 siblings, 1 reply; 12+ messages in thread From: Arno Wagner @ 2010-06-03 20:14 UTC (permalink / raw) To: dm-crypt 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [dm-crypt] Corrupted luks partition, help needed 2010-06-03 20:14 ` Arno Wagner @ 2010-06-03 20:48 ` Luca Berra 2010-06-03 20:56 ` Christoph Anton Mitterer 2010-06-03 22:07 ` Arno Wagner 0 siblings, 2 replies; 12+ messages in thread From: Luca Berra @ 2010-06-03 20:48 UTC (permalink / raw) To: dm-crypt 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 / \ ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [dm-crypt] Corrupted luks partition, help needed 2010-06-03 20:48 ` Luca Berra @ 2010-06-03 20:56 ` Christoph Anton Mitterer 2010-06-03 22:07 ` Arno Wagner 1 sibling, 0 replies; 12+ messages in thread From: Christoph Anton Mitterer @ 2010-06-03 20:56 UTC (permalink / raw) To: dm-crypt [-- 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 --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [dm-crypt] Corrupted luks partition, help needed 2010-06-03 20:48 ` Luca Berra 2010-06-03 20:56 ` Christoph Anton Mitterer @ 2010-06-03 22:07 ` Arno Wagner 2010-06-04 6:05 ` Panagiotis Malakoudis 2010-06-06 19:57 ` [dm-crypt] cryptsetup administration tool Ali Reza Sajedi 1 sibling, 2 replies; 12+ messages in thread From: Arno Wagner @ 2010-06-03 22:07 UTC (permalink / raw) To: dm-crypt 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [dm-crypt] Corrupted luks partition, help needed 2010-06-03 22:07 ` Arno Wagner @ 2010-06-04 6:05 ` Panagiotis Malakoudis 2010-06-04 8:54 ` Roscoe 2010-06-06 19:57 ` [dm-crypt] cryptsetup administration tool Ali Reza Sajedi 1 sibling, 1 reply; 12+ messages in thread From: Panagiotis Malakoudis @ 2010-06-04 6:05 UTC (permalink / raw) To: dm-crypt [-- 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 --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [dm-crypt] Corrupted luks partition, help needed 2010-06-04 6:05 ` Panagiotis Malakoudis @ 2010-06-04 8:54 ` Roscoe 0 siblings, 0 replies; 12+ messages in thread From: Roscoe @ 2010-06-04 8:54 UTC (permalink / raw) To: Panagiotis Malakoudis; +Cc: dm-crypt 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* [dm-crypt] cryptsetup administration tool 2010-06-03 22:07 ` Arno Wagner 2010-06-04 6:05 ` Panagiotis Malakoudis @ 2010-06-06 19:57 ` Ali Reza Sajedi 1 sibling, 0 replies; 12+ messages in thread From: Ali Reza Sajedi @ 2010-06-06 19:57 UTC (permalink / raw) To: dm-crypt Hello All, Does anyone know if there is a cryptsetup administration tool written in PERL. Any hint would be greatly appriciated. Best regards Ali ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2010-06-06 19:57 UTC | newest] Thread overview: 12+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-06-03 15:32 [dm-crypt] Corrupted luks partition, help needed Panagiotis Malakoudis 2010-06-03 15:51 ` Milan Broz 2010-06-03 16:16 ` Panagiotis Malakoudis 2010-06-03 18:12 ` Milan Broz 2010-06-03 18:05 ` Panagiotis Malakoudis 2010-06-03 20:14 ` Arno Wagner 2010-06-03 20:48 ` Luca Berra 2010-06-03 20:56 ` Christoph Anton Mitterer 2010-06-03 22:07 ` Arno Wagner 2010-06-04 6:05 ` Panagiotis Malakoudis 2010-06-04 8:54 ` Roscoe 2010-06-06 19:57 ` [dm-crypt] cryptsetup administration tool Ali Reza Sajedi
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.