* [dm-crypt] No key available for this passphrase @ 2012-09-08 9:03 Marcos 2012-09-08 13:35 ` Arno Wagner 0 siblings, 1 reply; 25+ messages in thread From: Marcos @ 2012-09-08 9:03 UTC (permalink / raw) To: dm-crypt Hi, I have a encrypted fs on my Archlinux laptop that I cannot unlock anymore: # cryptsetup luksOpen /dev/sda2 vgroup No key available for this passphrase I updated yesterday my system and booted once successfully into it. After that I used the machine and created a live Ubuntu USB for a friend and tested it booting into it, live mode. I shutted it down and after that I'm unable to unlock the key of my encrypted partition. I've done the following so far: * tested to write the passphrase using a US-layout keyboard to discard keymap problems * booted from a liveUSB and try to luksOpen it from there, with no success (using the right keymap, es_ES in my case) * plugged my harddisk via USB to another computer running Debian and tried to unlock it from there, no success neither. AFAICT the luksHeader is OK: # cryptsetup -v isLuks /dev/sda2 Command successful. I installed the system few years ago following this guide: http://www.pindarsign.de/webblog/?p=767 in case you want no know how luks was setup. Can any one give some hints on what to do now? Do you need more information about it? My last backup is from some time ago and I'm really worried about my data now. Thanks in advance, -- Marcos http://tenak.net/ ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [dm-crypt] No key available for this passphrase 2012-09-08 9:03 [dm-crypt] No key available for this passphrase Marcos @ 2012-09-08 13:35 ` Arno Wagner 2012-09-08 18:47 ` Marcos 0 siblings, 1 reply; 25+ messages in thread From: Arno Wagner @ 2012-09-08 13:35 UTC (permalink / raw) To: dm-crypt Hi, seems you have damaged the keyslot are in some way. (See FAQ Item 6.12) This is where a header-backup (See FAQ item 6.1ff) comes in, typically as the only way to recover. Other things you can try: If you have multiple passphrases, try them all. From what you describe, I do not see how you could have done damage. Have you maybe used the "encrypted partition" feature of Ubuntu? It has a known bug (see FAQ item 1.3) that makes it look like it maps LUKS partitions, but it really re-creates them, destroyuing the old data permanently. While the update is suspicuous, you being able to boot it once (I assume from war or cold reset) and the test with the other system should rule it out as root cause. Arno On Sat, Sep 08, 2012 at 10:03:42AM +0100, Marcos wrote: > Hi, > > I have a encrypted fs on my Archlinux laptop that I cannot unlock > anymore: > > # cryptsetup luksOpen /dev/sda2 vgroup > No key available for this passphrase > > I updated yesterday my system and booted once successfully into it. > After that I used the machine and created a live Ubuntu USB for a > friend and tested it booting into it, live mode. I shutted it down > and after that I'm unable to unlock the key of my encrypted > partition. > > I've done the following so far: > > * tested to write the passphrase using a US-layout keyboard to > discard keymap problems > * booted from a liveUSB and try to luksOpen it from there, with no > success (using the right keymap, es_ES in my case) > * plugged my harddisk via USB to another computer running Debian > and tried to unlock it from there, no success neither. > > AFAICT the luksHeader is OK: > > # cryptsetup -v isLuks /dev/sda2 > Command successful. > > I installed the system few years ago following this guide: > http://www.pindarsign.de/webblog/?p=767 in case you want no know how > luks was setup. > > Can any one give some hints on what to do now? Do you need more > information about it? > > My last backup is from some time ago and I'm really worried about my > data now. > > Thanks in advance, > -- > Marcos > http://tenak.net/ > _______________________________________________ > 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: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F ---- One of the painful things about our time is that those who feel certainty are stupid, and those with any imagination and understanding are filled with doubt and indecision. -- Bertrand Russell ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [dm-crypt] No key available for this passphrase 2012-09-08 13:35 ` Arno Wagner @ 2012-09-08 18:47 ` Marcos 2012-09-08 20:02 ` Arno Wagner 0 siblings, 1 reply; 25+ messages in thread From: Marcos @ 2012-09-08 18:47 UTC (permalink / raw) To: dm-crypt Hi, On 08.09.2012 14:35, Arno Wagner wrote: > seems you have damaged the keyslot are in some way. > (See FAQ Item 6.12) This is where a header-backup > (See FAQ item 6.1ff) comes in, typically as the only way > to recover. A header-backup that I don't have, before having this problem haven't read about such headers. The doc I read to setup the encrypted disk didn't mention it at all. I for sure will do a backup on my next reinstall (which I expect to be soon if I can not recover my data :() > Other things you can try: If you have multiple > passphrases, try them all. What you mean with multiple passphrases? I just remember setting up only one. > From what you describe, I do not see how you could have > done damage. Have you maybe used the "encrypted partition" > feature of Ubuntu? It has a known bug (see FAQ item 1.3) > that makes it look like it maps LUKS partitions, but it > really re-creates them, destroyuing the old data permanently. I didn't use anything related with encrypted partitions from the live USB. I totally ignore if the liveUSB did something by itself without asking anything. So, from what I know, I did nothing that could have messed up the headers. > While the update is suspicuous, you being able to boot it > once (I assume from war or cold reset) and the test with the > other system should rule it out as root cause. Yes, the boot I did was from a shutted down computer, no from a suspend or hibernate. I suspect that my data is now completely useless :( From what I have read, I've understood that the passphrase unlocks the key that is used for encryption and that such key is not derived from the passphrase at the time of setup? Because if the key can be derived from the passphrase, knowing the passphrase, could the key be retrieved or regenerated in some way? I just want to be sure that the data stored in the encrypted volume is just rubbish before reusing the disk. Thanks a lot, -- Marcos http://tenak.net/ ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [dm-crypt] No key available for this passphrase 2012-09-08 18:47 ` Marcos @ 2012-09-08 20:02 ` Arno Wagner 2012-09-08 20:51 ` Marcos 2012-09-08 22:45 ` [dm-crypt] " Matthias Schniedermeyer 0 siblings, 2 replies; 25+ messages in thread From: Arno Wagner @ 2012-09-08 20:02 UTC (permalink / raw) To: dm-crypt On Sat, Sep 08, 2012 at 07:47:00PM +0100, Marcos wrote: > Hi, > > On 08.09.2012 14:35, Arno Wagner wrote: > >seems you have damaged the keyslot are in some way. > >(See FAQ Item 6.12) This is where a header-backup > >(See FAQ item 6.1ff) comes in, typically as the only way > >to recover. > > A header-backup that I don't have, before having this > problem haven't read about such headers. The doc I read to > setup the encrypted disk didn't mention it at all. I for > sure will do a backup on my next reinstall (which I expect > to be soon if I can not recover my data :() Sorry about that. One reason I started writing the FAQ is that people kept running into this problem. > >Other things you can try: If you have multiple > >passphrases, try them all. > > What you mean with multiple passphrases? I just remember > setting up only one. You can have up to 8 with LUKS. Each gets it own key-slot. Unfortunately, the key-slot with the highest risk to get damaged is the first one and that is where a single passphrase ends up in if you do not override the placement default. > >From what you describe, I do not see how you could have > >done damage. Have you maybe used the "encrypted partition" > >feature of Ubuntu? It has a known bug (see FAQ item 1.3) > >that makes it look like it maps LUKS partitions, but it > >really re-creates them, destroyuing the old data permanently. > > I didn't use anything related with encrypted partitions from > the live USB. I totally ignore if the liveUSB did something by > itself without asking anything. It should not. > So, from what I know, I did > nothing that could have messed up the headers. Hmm. Ok. Next thing is to look at the key-slot areas with a hex dumper. For now placement is described in FAQ item 6.12. As fiorst step, look at the output of cryptsetup luksDump <encrypted partition> to determine your pasphrase is indeed in slot 0. then look at that slow. One way is to use something like hd <encrypted partition> | less At the very beginning you find the LUKS header (with the magic string "LUKS" 0xBA 0xBE and some plain0-text cipher and hash specs) . Then look at keyslot 0 (at 0x1000-0x20400 with default parameters). If there is anything appearing non-random in there, then it has been destroyed. The nature of that non-random data points to the source. I have meant to write a LUKS keyslot-checker for some time now, but never got around to it. Hmm. Maybe something to pass the time this weekend. Anyways, don't do anything rash. Somethinges things can be fixed but careful diagnosis is the key to that. > >While the update is suspicuous, you being able to boot it > >once (I assume from war or cold reset) and the test with the > >other system should rule it out as root cause. > > Yes, the boot I did was from a shutted down computer, no from > a suspend or hibernate. That that was a giood validation for the update still working. > I suspect that my data is now completely useless :( > From what I have read, I've understood that the passphrase > unlocks the key that is used for encryption and that such > key is not derived from the passphrase at the time of setup? Yes. > Because if the key can be derived from the passphrase, knowing > the passphrase, could the key be retrieved or regenerated in > some way? That is true, but not the reason to do it this way. The reason is that when you have a master key that gets unlocked via passphrase, than you get "enterprise features", like more than one passphrase and the ability to change/delete passphrases securely (i.e. the changed/removed one becomes completely useless) without re-encrypting everything. > I just want to be sure that the data stored in the encrypted > volume is just rubbish before reusing the disk. That is not really easy to find out. As your LUKS header is good, damage to the keyslot-area looks like the most likely scenario. Test it as above. Arno -- Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@wagner.name GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F ---- One of the painful things about our time is that those who feel certainty are stupid, and those with any imagination and understanding are filled with doubt and indecision. -- Bertrand Russell ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [dm-crypt] No key available for this passphrase 2012-09-08 20:02 ` Arno Wagner @ 2012-09-08 20:51 ` Marcos 2012-09-08 22:47 ` Arno Wagner 2012-09-08 23:16 ` [dm-crypt] Re2: " Arno Wagner 2012-09-08 22:45 ` [dm-crypt] " Matthias Schniedermeyer 1 sibling, 2 replies; 25+ messages in thread From: Marcos @ 2012-09-08 20:51 UTC (permalink / raw) To: dm-crypt Hi, On 08.09.2012 21:02, Arno Wagner wrote: > Hmm. Ok. Next thing is to look at the key-slot areas with > a hex dumper. For now placement is described in FAQ item > 6.12. > > As fiorst step, look at the output of > > cryptsetup luksDump <encrypted partition> > > to determine your pasphrase is indeed in slot 0. It is: # cryptsetup luksDump /dev/sdb2 LUKS header information for /dev/sdb2 Version: 1 Cipher name: aes Cipher mode: lrw-benbi Hash spec: sha1 Payload offset: 3016 MK bits: 384 MK digest: 31 14 46 75 66 60 2d a0 30 b3 c6 8a df 5b 72 7b ee c4 ed 66 MK salt: a3 6e 85 75 7b 4a 04 a7 30 8a 58 f9 db b9 36 1c cd d8 c0 85 75 83 81 0a 8f c3 35 ec 3c f9 bd e6 MK iterations: 10 UUID: ac6dbe7f-30ab-4fe6-8ddc-f7cec045a791 Key Slot 0: ENABLED Iterations: 254001 Salt: 63 d8 01 44 98 40 ef 15 12 b2 cc fe 2d f4 6f f5 f2 e7 f2 d8 6c d5 5a af 3e ba 6c 1c e5 1e e6 e5 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 > then look at that slow. One way is to use something like > > hd <encrypted partition> | less > > At the very beginning you find the LUKS header (with the magic > string "LUKS" 0xBA 0xBE and some plain0-text cipher and hash > specs) . So far, so good: 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 6c 72 77 2d 62 65 6e 62 |........lrw-benb| 00000030 69 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |i...............| 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 0b c8 00 00 00 30 |...............0| > Then look at keyslot 0 (at 0x1000-0x20400 with default > parameters). If there is anything appearing non-random in there, > then it has been destroyed. The nature of that non-random data points > to the source. Seems quite random to me: 00001000 d3 33 50 4a ca d2 2f 3f f3 9b 96 5b fd 6c 1e 2e |.3PJ../?...[.l..| 00001010 91 33 97 fc 49 39 57 43 55 45 50 47 a9 7c c3 49 |.3..I9WCUEPG.|.I| 00001020 f0 75 9b 54 15 74 34 13 50 34 c9 84 b4 95 df 57 |.u.T.t4.P4.....W| 00001030 15 6d 5a 34 12 6d ab 0d 04 94 19 f4 c2 72 bb b0 |.mZ4.m.......r..| 00001040 dc 26 83 59 5f 6c 80 29 84 1a df b4 76 92 4c 61 |.&.Y_l.)....v.La| 00001050 96 1c 5f df d7 69 21 28 d0 c7 5a 4c 08 18 90 85 |.._..i!(..ZL....| 00001060 94 01 48 d7 d3 31 f0 b6 19 39 a5 62 92 f2 73 19 |..H..1...9.b..s.| 00001070 2d d6 6c 4a fe e7 49 ee ff f2 f5 33 1f 4f 7d 1e |-.lJ..I....3.O}.| 00001080 1f 79 fd aa 4a a7 26 8d 22 bb 64 44 de d4 ba 6d |.y..J.&.".dD...m| 00001090 4f 99 13 38 c8 58 00 35 ab b7 d7 b2 af f9 80 1e |O..8.X.5........| 000010a0 d4 7b de f2 a3 fc 98 ee 1e 11 ab 7e dd 4c b5 c1 |.{.........~.L..| 000010b0 9c 6d f4 ed fd fe dc 44 1f 8f 4f 2f f3 3e fd 81 |.m.....D..O/.>..| 000010c0 98 0c bb d5 36 79 c8 d8 b4 39 a1 74 eb 43 d5 44 |....6y...9.t.C.D| 000010d0 7b c6 91 11 c0 6e dd 44 32 23 df 7c eb af d9 63 |{....n.D2#.|...c| 000010e0 59 fc b9 ba d1 15 ca 9b 64 0e b8 a5 28 69 b0 86 |Y.......d...(i..| 000010f0 6d db d5 47 15 4d fb 74 bf 45 04 45 54 3b fc ce |m..G.M.t.E.ET;..| 00001100 31 62 6b 92 61 31 25 1e 9b bf 4c 7f 70 7f 87 77 |1bk.a1%...L.p..w| 00001110 bf 72 d1 d6 8f 8f f9 e9 07 1f 8e 4f 91 39 25 00 |.r.........O.9%.| 00001120 8a fb 5b 1d 88 08 18 f2 ca 73 47 0a 23 33 02 ae |..[......sG.#3..| 00001130 81 c9 64 8a d7 c0 87 5c 15 d1 cc ac 3a 3e e1 6a |..d....\....:>.j| 00001140 ee 11 42 ac 9b 34 52 72 4c 22 18 13 64 c2 fd 98 |..B..4RrL"..d...| 00001150 e3 3e c6 dd 2b aa 5f 7a 6d e6 2a 37 35 95 6d 7f |.>..+._zm.*75.m.| 00001160 ea db 53 1c 87 35 e9 ed da ba cb 5b 52 54 ab 1e |..S..5.....[RT..| 00001170 48 d3 b5 85 5a 58 03 37 01 a9 ad 49 13 6b 7b 7d |H...ZX.7...I.k{}| 00001180 80 12 a1 c5 44 3a 38 2a d0 a1 fa 46 4b a9 55 ad |....D:8*...FK.U.| 00001190 c8 6a ad 5c d2 81 35 c5 82 31 31 e1 99 89 47 bb |.j.\..5..11...G.| 000011a0 c8 fe 7c b5 7e 8d 9b c7 e3 a0 6b 1c 3e 67 da 33 |..|.~.....k.>g.3| And it follows similarly... BUT: Just before 0x1000 I have: 00000ff0 00 00 00 00 00 00 53 57 41 50 53 50 41 43 45 32 |......SWAPSPACE2| I don't know if it's relevant or not, but (being the first time I look at a block device with an hex dumper) I find suspicious to have such "tag" there... > I have meant to write a LUKS keyslot-checker for some time > now, but never got around to it. Hmm. Maybe something to > pass the time this weekend. ;-) > Anyways, don't do anything rash. Somethinges things can be > fixed but careful diagnosis is the key to that. Will be patient then. >> Because if the key can be derived from the passphrase, knowing >> the passphrase, could the key be retrieved or regenerated in >> some way? > > > That is true, but not the reason to do it this way. The reason > is that when you have a master key that gets unlocked via > passphrase, than you get "enterprise features", like more than > one passphrase and the ability to change/delete passphrases > securely (i.e. the changed/removed one becomes completely > useless) without re-encrypting everything. I see. Thanks a lot for all the explanations and how detailed they are, I really appreciate it. -- Marcos http://tenak.net/ ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [dm-crypt] No key available for this passphrase 2012-09-08 20:51 ` Marcos @ 2012-09-08 22:47 ` Arno Wagner 2012-09-09 12:53 ` Marcos 2012-09-08 23:16 ` [dm-crypt] Re2: " Arno Wagner 1 sibling, 1 reply; 25+ messages in thread From: Arno Wagner @ 2012-09-08 22:47 UTC (permalink / raw) To: dm-crypt On Sat, Sep 08, 2012 at 09:51:29PM +0100, Marcos wrote: > Hi, > > On 08.09.2012 21:02, Arno Wagner wrote: > >Hmm. Ok. Next thing is to look at the key-slot areas with > >a hex dumper. For now placement is described in FAQ item > >6.12. > > > >As fiorst step, look at the output of > > > > cryptsetup luksDump <encrypted partition> > > > >to determine your pasphrase is indeed in slot 0. > > It is: > > # cryptsetup luksDump /dev/sdb2 > LUKS header information for /dev/sdb2 > > Version: 1 > Cipher name: aes > Cipher mode: lrw-benbi Wups, what is that? Quite non-standard. Did you select that yourself? > Hash spec: sha1 > Payload offset: 3016 > MK bits: 384 With that your first keyslot should be from 0x1000 to 0x2ee00. > MK digest: 31 14 46 75 66 60 2d a0 30 b3 c6 8a df 5b 72 7b ee > c4 ed 66 > MK salt: a3 6e 85 75 7b 4a 04 a7 30 8a 58 f9 db b9 36 1c > cd d8 c0 85 75 83 81 0a 8f c3 35 ec 3c f9 bd e6 > MK iterations: 10 That likely means it is the old header. Newer versions of cryptsetup use some larger number here, based on timing. > UUID: ac6dbe7f-30ab-4fe6-8ddc-f7cec045a791 > > Key Slot 0: ENABLED > Iterations: 254001 Pretty large. Unless you have a liquid-nitrogen cooled CPU, did you increase the iteration time? > Salt: 63 d8 01 44 98 40 ef 15 12 b2 cc fe 2d f4 6f f5 > f2 e7 f2 d8 6c d5 5a af 3e ba 6c 1c e5 1e e6 e5 > 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 > > > >then look at that slow. One way is to use something like > > > > hd <encrypted partition> | less > > > >At the very beginning you find the LUKS header (with the magic > >string "LUKS" 0xBA 0xBE and some plain0-text cipher and hash > >specs) . > > So far, so good: > > 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 6c 72 77 2d 62 65 6e 62 > |........lrw-benb| > 00000030 69 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > |i...............| > 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 0b c8 00 00 00 30 > |...............0| > > > >Then look at keyslot 0 (at 0x1000-0x20400 with default > >parameters). If there is anything appearing non-random in there, > >then it has been destroyed. The nature of that non-random data points > >to the source. > > Seems quite random to me: Have you looked at the whole keyslot up to 0x2ee00? > 00001000 d3 33 50 4a ca d2 2f 3f f3 9b 96 5b fd 6c 1e 2e > |.3PJ../?...[.l..| > 00001010 91 33 97 fc 49 39 57 43 55 45 50 47 a9 7c c3 49 > |.3..I9WCUEPG.|.I| > 00001020 f0 75 9b 54 15 74 34 13 50 34 c9 84 b4 95 df 57 > |.u.T.t4.P4.....W| > 00001030 15 6d 5a 34 12 6d ab 0d 04 94 19 f4 c2 72 bb b0 > |.mZ4.m.......r..| > 00001040 dc 26 83 59 5f 6c 80 29 84 1a df b4 76 92 4c 61 > |.&.Y_l.)....v.La| > 00001050 96 1c 5f df d7 69 21 28 d0 c7 5a 4c 08 18 90 85 > |.._..i!(..ZL....| > 00001060 94 01 48 d7 d3 31 f0 b6 19 39 a5 62 92 f2 73 19 > |..H..1...9.b..s.| > 00001070 2d d6 6c 4a fe e7 49 ee ff f2 f5 33 1f 4f 7d 1e > |-.lJ..I....3.O}.| > 00001080 1f 79 fd aa 4a a7 26 8d 22 bb 64 44 de d4 ba 6d > |.y..J.&.".dD...m| > 00001090 4f 99 13 38 c8 58 00 35 ab b7 d7 b2 af f9 80 1e > |O..8.X.5........| > 000010a0 d4 7b de f2 a3 fc 98 ee 1e 11 ab 7e dd 4c b5 c1 > |.{.........~.L..| > 000010b0 9c 6d f4 ed fd fe dc 44 1f 8f 4f 2f f3 3e fd 81 > |.m.....D..O/.>..| > 000010c0 98 0c bb d5 36 79 c8 d8 b4 39 a1 74 eb 43 d5 44 > |....6y...9.t.C.D| > 000010d0 7b c6 91 11 c0 6e dd 44 32 23 df 7c eb af d9 63 > |{....n.D2#.|...c| > 000010e0 59 fc b9 ba d1 15 ca 9b 64 0e b8 a5 28 69 b0 86 > |Y.......d...(i..| > 000010f0 6d db d5 47 15 4d fb 74 bf 45 04 45 54 3b fc ce > |m..G.M.t.E.ET;..| > 00001100 31 62 6b 92 61 31 25 1e 9b bf 4c 7f 70 7f 87 77 > |1bk.a1%...L.p..w| > 00001110 bf 72 d1 d6 8f 8f f9 e9 07 1f 8e 4f 91 39 25 00 > |.r.........O.9%.| > 00001120 8a fb 5b 1d 88 08 18 f2 ca 73 47 0a 23 33 02 ae > |..[......sG.#3..| > 00001130 81 c9 64 8a d7 c0 87 5c 15 d1 cc ac 3a 3e e1 6a > |..d....\....:>.j| > 00001140 ee 11 42 ac 9b 34 52 72 4c 22 18 13 64 c2 fd 98 > |..B..4RrL"..d...| > 00001150 e3 3e c6 dd 2b aa 5f 7a 6d e6 2a 37 35 95 6d 7f > |.>..+._zm.*75.m.| > 00001160 ea db 53 1c 87 35 e9 ed da ba cb 5b 52 54 ab 1e > |..S..5.....[RT..| > 00001170 48 d3 b5 85 5a 58 03 37 01 a9 ad 49 13 6b 7b 7d > |H...ZX.7...I.k{}| > 00001180 80 12 a1 c5 44 3a 38 2a d0 a1 fa 46 4b a9 55 ad > |....D:8*...FK.U.| > 00001190 c8 6a ad 5c d2 81 35 c5 82 31 31 e1 99 89 47 bb > |.j.\..5..11...G.| > 000011a0 c8 fe 7c b5 7e 8d 9b c7 e3 a0 6b 1c 3e 67 da 33 > |..|.~.....k.>g.3| > > And it follows similarly... BUT: Just before 0x1000 I have: > > 00000ff0 00 00 00 00 00 00 53 57 41 50 53 50 41 43 45 32 > |......SWAPSPACE2| That is not a problem. There is some free space between header and first keyslot. Older versions of cryptsetup do not wipe that area if I remember correctly. > I don't know if it's relevant or not, but (being the first time I > look at a block > device with an hex dumper) I find suspicious to have such "tag" > there... > > >I have meant to write a LUKS keyslot-checker for some time > >now, but never got around to it. Hmm. Maybe something to > >pass the time this weekend. > > ;-) > > >Anyways, don't do anything rash. Somethinges things can be > >fixed but careful diagnosis is the key to that. > > Will be patient then. Most people are hosed in your situations, but there have been some miraculous recoveries. So really knowing what happened is the key. Arno -- Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@wagner.name GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F ---- One of the painful things about our time is that those who feel certainty are stupid, and those with any imagination and understanding are filled with doubt and indecision. -- Bertrand Russell ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [dm-crypt] No key available for this passphrase 2012-09-08 22:47 ` Arno Wagner @ 2012-09-09 12:53 ` Marcos 2012-09-09 13:49 ` Arno Wagner 0 siblings, 1 reply; 25+ messages in thread From: Marcos @ 2012-09-09 12:53 UTC (permalink / raw) To: dm-crypt Hi, On 08.09.2012 23:47, Arno Wagner wrote: > Wups, what is that? Quite non-standard. Did you select that yourself? As per the docs I read back in the time, yes, I selected that cipher. >> Hash spec: sha1 >> Payload offset: 3016 >> MK bits: 384 > > > With that your first keyslot should be from 0x1000 to 0x2ee00. Find the 'hd' dump at [1], from 0x1000 to 0x2ee00 (didn't attached because its size is 329K). >> Key Slot 0: ENABLED >> Iterations: 254001 > > Pretty large. Unless you have a liquid-nitrogen cooled > CPU, did you increase the iteration time? Nope, actually, the problem is on a laptop hard disk... > Have you looked at the whole keyslot up to 0x2ee00? I haven't untill you pointed me to do it with this email :) It's attached. And having it done after running the code you attach in another email, going straight to the low-entropy blocks that it points to, I have found what seems an image file: 0002a000 ff d8 ff e0 00 10 4a 46 49 46 00 01 01 01 00 90 |......JFIF......| 0002a010 00 90 00 00 ff e1 00 16 45 78 69 66 00 00 4d 4d |........Exif..MM| 0002a020 00 2a 00 00 00 08 00 00 00 00 00 00 ff fe 00 17 |.*..............| 0002a030 43 72 65 61 74 65 64 20 77 69 74 68 20 54 68 65 |Created with The| 0002a040 20 47 49 4d 50 ff db 00 43 00 05 03 04 04 04 03 | GIMP...C.......| One thing I don't understand: as per the docs I read for setting the encryption, I selected a size of 384 bits for the key (that in the case of lrw just 256 are used). What are we looking for at 0x2ee00 far? > Most people are hosed in your situations, but there have been > some miraculous recoveries. So really knowing what happened > is the key. I suppose it. With an analysis of what happened it's all easier. Thanks, [1] http://dl.tenak.net/563cc336/hd_devsdb2_0x1000-0x2ee00.dump.bz2 -- Marcos http://tenak.net/ ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [dm-crypt] No key available for this passphrase 2012-09-09 12:53 ` Marcos @ 2012-09-09 13:49 ` Arno Wagner 2012-09-09 14:06 ` Marcos 0 siblings, 1 reply; 25+ messages in thread From: Arno Wagner @ 2012-09-09 13:49 UTC (permalink / raw) To: dm-crypt On Sun, Sep 09, 2012 at 01:53:08PM +0100, Marcos wrote: > Hi, > > On 08.09.2012 23:47, Arno Wagner wrote: > >Wups, what is that? Quite non-standard. Did you select that yourself? > > As per the docs I read back in the time, yes, I selected that cipher. > > >>Hash spec: sha1 > >>Payload offset: 3016 > >>MK bits: 384 > > > > > >With that your first keyslot should be from 0x1000 to 0x2ee00. > > Find the 'hd' dump at [1], from 0x1000 to 0x2ee00 (didn't attached > because its size is 329K). > > >>Key Slot 0: ENABLED > >> Iterations: 254001 > > > >Pretty large. Unless you have a liquid-nitrogen cooled > >CPU, did you increase the iteration time? > > Nope, actually, the problem is on a laptop hard disk... > > >Have you looked at the whole keyslot up to 0x2ee00? > > I haven't untill you pointed me to do it with this email :) > It's attached. > > And having it done after running the code you attach in another > email, going straight to the low-entropy blocks that it points > to, I have found what seems an image file: > > 0002a000 ff d8 ff e0 00 10 4a 46 49 46 00 01 01 01 00 90 > |......JFIF......| > 0002a010 00 90 00 00 ff e1 00 16 45 78 69 66 00 00 4d 4d > |........Exif..MM| > 0002a020 00 2a 00 00 00 08 00 00 00 00 00 00 ff fe 00 17 > |.*..............| > 0002a030 43 72 65 61 74 65 64 20 77 69 74 68 20 54 68 65 |Created > with The| > 0002a040 20 47 49 4d 50 ff db 00 43 00 05 03 04 04 04 03 | > GIMP...C.......| Well, on one hand I am glad my tool actually works, on the other hand this means your data is really gone. Wonder how that got in there though. Maybe used as swap because of the leftover signature? > One thing I don't understand: as per the docs I read for setting > the encryption, I selected a size of 384 bits for the key (that > in the case of lrw just 256 are used). What are we looking for > at 0x2ee00 far? LUKS splits the key (really: blows it up) with the AF splitter. It blows it up to exactly 4000 times the original key size. Your key is 384 bit = 48 B. 48 * 4000 = 192'000 = 0x2ee00. And then add the start-offset (which I forgot ;-) to get 0x2fe00. > >Most people are hosed in your situations, but there have been > >some miraculous recoveries. So really knowing what happened > >is the key. > > I suppose it. With an analysis of what happened it's all easier. > > Thanks, No problem. Arno -- Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@wagner.name GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F ---- One of the painful things about our time is that those who feel certainty are stupid, and those with any imagination and understanding are filled with doubt and indecision. -- Bertrand Russell ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [dm-crypt] No key available for this passphrase 2012-09-09 13:49 ` Arno Wagner @ 2012-09-09 14:06 ` Marcos 0 siblings, 0 replies; 25+ messages in thread From: Marcos @ 2012-09-09 14:06 UTC (permalink / raw) To: dm-crypt Hi, On 09.09.2012 14:49, Arno Wagner wrote: > Well, on one hand I am glad my tool actually works, on the > other hand this means your data is really gone. Thanks for your time and knowledge :-) I'm gonna drink a toast for the lost bits. Then I probably should start backing up my stuff! > Wonder how that got in there though. Maybe used as swap because > of the leftover signature? That would be insteresting to know. >> One thing I don't understand: as per the docs I read for setting >> the encryption, I selected a size of 384 bits for the key (that >> in the case of lrw just 256 are used). What are we looking for >> at 0x2ee00 far? > > LUKS splits the key (really: blows it up) with the AF splitter. > It blows it up to exactly 4000 times the original key size. > Your key is 384 bit = 48 B. 48 * 4000 = 192'000 = 0x2ee00. > And then add the start-offset (which I forgot ;-) to get > 0x2fe00. Now I see :-) Again, thanks a lot! -- Marcos http://tenak.net/ ^ permalink raw reply [flat|nested] 25+ messages in thread
* [dm-crypt] Re2: No key available for this passphrase 2012-09-08 20:51 ` Marcos 2012-09-08 22:47 ` Arno Wagner @ 2012-09-08 23:16 ` Arno Wagner 2012-09-09 12:58 ` Marcos 1 sibling, 1 reply; 25+ messages in thread From: Arno Wagner @ 2012-09-08 23:16 UTC (permalink / raw) To: dm-crypt You also should probably look at the key-encoding angle further. It is not quite as simple as it seems, see FAQ item 1.2, "PASSPHRASE CHARACTER SET". The problem is that not only may your keymap change after some updates and you end up inputting the wrong characters, you may also enter the same characters (visible), but theior encoding has changed. Your one successful mapping after update may not be as good as it seems. If you enter the passphrase before the encoding is set, but after that the system changes the encoding for password entry (something to it may do on first boot after update...), you could enter your passphrase once, it works, but then the system changes it and it does not work again. The thing is that all except the 94 printable characters from http://en.wikipedia.org/wiki/ASCII change their encoding when the system is updated to use UTF-8. Cryptestup reads the passphrase in binary and the characters not in ASCII 7-bit will look different to it. Your header and keyslot looks fine, we have this one successful unlock, but not additional ones. This makes me kind of suspicuous. So: - Do you have any characters in your passphrase that are not in the table on http://en.wikipedia.org/wiki/ASCII? - Has the system possibly changed the character encoding? - Did the second system you tried the unlock on already have the update you did on the first system? Arno -- Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@wagner.name GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F ---- One of the painful things about our time is that those who feel certainty are stupid, and those with any imagination and understanding are filled with doubt and indecision. -- Bertrand Russell ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [dm-crypt] Re2: No key available for this passphrase 2012-09-08 23:16 ` [dm-crypt] Re2: " Arno Wagner @ 2012-09-09 12:58 ` Marcos 0 siblings, 0 replies; 25+ messages in thread From: Marcos @ 2012-09-09 12:58 UTC (permalink / raw) To: dm-crypt Hi, On 09.09.2012 00:16, Arno Wagner wrote: > - Do you have any characters in your passphrase that are > not in the table on http://en.wikipedia.org/wiki/ASCII? No, all of them are inside the ASCII space. > - Has the system possibly changed the character encoding? It shouldn't. > - Did the second system you tried the unlock on already have > the update you did on the first system? They are different distros so they have not the same collection of software on same versions. But both of them are quite up to date. Mine is an Archlinux updated just 3 days ago and the other is a Debian Testing, probably upgraded during the last week or two. Thanks, -- Marcos http://tenak.net/ ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [dm-crypt] No key available for this passphrase 2012-09-08 20:02 ` Arno Wagner 2012-09-08 20:51 ` Marcos @ 2012-09-08 22:45 ` Matthias Schniedermeyer 2012-09-09 8:45 ` Milan Broz 1 sibling, 1 reply; 25+ messages in thread From: Matthias Schniedermeyer @ 2012-09-08 22:45 UTC (permalink / raw) To: dm-crypt On 08.09.2012 22:02, Arno Wagner wrote: > > You can have up to 8 with LUKS. Each gets it own key-slot. > Unfortunately, the key-slot with the highest risk to get > damaged is the first one and that is where a single passphrase > ends up in if you do not override the placement default. If that happens so often, why not change the default and place the first key in slot 8? (Assuming that can be done without significant compatibility issues) Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [dm-crypt] No key available for this passphrase 2012-09-08 22:45 ` [dm-crypt] " Matthias Schniedermeyer @ 2012-09-09 8:45 ` Milan Broz 2012-09-09 13:42 ` Arno Wagner 0 siblings, 1 reply; 25+ messages in thread From: Milan Broz @ 2012-09-09 8:45 UTC (permalink / raw) To: dm-crypt On 09/09/2012 12:45 AM, Matthias Schniedermeyer wrote: > On 08.09.2012 22:02, Arno Wagner wrote: >> >> You can have up to 8 with LUKS. Each gets it own key-slot. >> Unfortunately, the key-slot with the highest risk to get >> damaged is the first one and that is where a single passphrase >> ends up in if you do not override the placement default. If most of installation it uses only the first slot, you can hardly notice that other (unused) were corrupted as well :) Most of programs formatting data today (mkfs, mkswap, lvm, mdadm...) wipes more data, usually at least the first 4KB. (mkswap should warn if it detects other signature, it is already using libblkid. In fact I thought it was fixed years ago...) > If that happens so often, why not change the default and place the first > key in slot 8? > (Assuming that can be done without significant compatibility issues) No, this is just hiding problem. So it will be corrupted after first swap use (in this case)... Milan ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [dm-crypt] No key available for this passphrase 2012-09-09 8:45 ` Milan Broz @ 2012-09-09 13:42 ` Arno Wagner 0 siblings, 0 replies; 25+ messages in thread From: Arno Wagner @ 2012-09-09 13:42 UTC (permalink / raw) To: dm-crypt On Sun, Sep 09, 2012 at 10:45:18AM +0200, Milan Broz wrote: > On 09/09/2012 12:45 AM, Matthias Schniedermeyer wrote: > > On 08.09.2012 22:02, Arno Wagner wrote: > >> > >> You can have up to 8 with LUKS. Each gets it own key-slot. > >> Unfortunately, the key-slot with the highest risk to get > >> damaged is the first one and that is where a single passphrase > >> ends up in if you do not override the placement default. > > If most of installation it uses only the first slot, you can hardly > notice that other (unused) were corrupted as well :) > > Most of programs formatting data today (mkfs, mkswap, lvm, mdadm...) > wipes more data, usually at least the first 4KB. > > (mkswap should warn if it detects other signature, it is already > using libblkid. In fact I thought it was fixed years ago...) I think the OP sees a old swap signature that was not wiped by a very old cryptsetup. Hmm. Come to think of it, could that signature have served to make some broken script auto-detect the LUKS container as swap? If the Ubuntu life-CD though here was some nice space to use as swap, it could have mangled the keyslot. > > If that happens so often, why not change the default and place the first > > key in slot 8? > > (Assuming that can be done without significant compatibility issues) > > No, this is just hiding problem. > So it will be corrupted after first swap use (in this case)... Indeed. Makes things even harder to diagnose. The proper way is for others to check for possible signatures and warn. Unfortunately we have no way of ensuring that. Arno -- Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@wagner.name GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F ---- One of the painful things about our time is that those who feel certainty are stupid, and those with any imagination and understanding are filled with doubt and indecision. -- Bertrand Russell ^ permalink raw reply [flat|nested] 25+ messages in thread
* [dm-crypt] No key available for this passphrase
@ 2013-01-25 17:53 Sebastian
2013-01-25 19:40 ` Arno Wagner
0 siblings, 1 reply; 25+ messages in thread
From: Sebastian @ 2013-01-25 17:53 UTC (permalink / raw)
To: dm-crypt
Hello,
I have quite a problem here with my notebook (debian squeeze and luks/dm-crypt
encrypted LVM).
After shutting it down yesterday, it did not let me unlock the encrypted disk
this morning.
I already found the post from September 2012 in the mailing list, but it did not
exactly match my case (everything looks fine, not overwritten by SWAP data)
Header Information looks OK to me:
# cryptsetup luksDump /dev/sda2
LUKS header information for /dev/sda2
Version: 1
Cipher name: aes
Cipher mode: cbc-essiv:sha256
Hash spec: sha1
Payload offset: 2056
MK bits: 256
MK digest: 53 44 c2 4d b0 9e c5 73 ef fa d7 12 4f dd f0 75 64 3b 88 ad
MK salt: 50 5f a9 69 21 6e 21 ac db 09 bd 79 b0 9b 9b 1e
14 2a 5d e4 46 2b 4d 9c 49 e3 9f 7d f9 d7 64 84
MK iterations: 10
UUID: b89fe8ad-3aea-4f27-9448-06e75fd8a05a
Key Slot 0: ENABLED
Iterations: 75899
Salt: 2d 2b 66 4c 57 eb ff e7 7f 63 14 8f c5 3b 6b aa
38 53 2d 52 52 b6 d9 cc 84 b0 1a 11 bd cf 88 70
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
Looking closer to the header (exported to file via luksHeaderBackup), right
after the initial information also shown by luksDump up to address 0x1000 (first
keyslot) is filled with zeroes, from 0x1000 until the end of the file random
data with no ASCII that would indicate files (e.g. header informations) or a
partition table.
The key slot checker though, gives me this output:
./chk_luks_keyslots /home/r4pt0r/notebook/luksheader.img
Sectors with entropy below threshold (0.850000):
Keyslot 0: start: 0x1000
position: 0x10000 entropy: 0.625023
Keyslot 1: start: 0x21000
keyslot not in use
Keyslot 2: start: 0x41000
keyslot not in use
Keyslot 3: start: 0x61000
keyslot not in use
Keyslot 4: start: 0x81000
keyslot not in use
Keyslot 5: start: 0xa1000
keyslot not in use
Keyslot 6: start: 0xc1000
keyslot not in use
Keyslot 7: start: 0xe1000
keyslot not in use
So the entropy seems to be too low? But where does the address 0x10000 come
from? shouldn't the key start at 0x1000 similar to its slot?
I HAD an backup of the header on USB stick - the Notebook was set up around 3-4
years ago but i really found my old backup-stick (32MB) where also gpg-keys and
other small files were backed up.
BUT: the stick seems to be broken :( It's not recognized by any PC and the LED
doesn't light up...
As the Notebook is usually put to sleep-mode I really can't remember what
updates were installed since the last reboot.
Is there any possibility the key is not damaged and data can be recovered?
Thanks for any help!
Sebastian
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: [dm-crypt] No key available for this passphrase 2013-01-25 17:53 Sebastian @ 2013-01-25 19:40 ` Arno Wagner 2013-01-25 19:57 ` Sebastian 0 siblings, 1 reply; 25+ messages in thread From: Arno Wagner @ 2013-01-25 19:40 UTC (permalink / raw) To: dm-crypt Answer below inline. On Fri, Jan 25, 2013 at 05:53:19PM +0000, Sebastian wrote: > Hello, > > I have quite a problem here with my notebook (debian squeeze and luks/dm-crypt > encrypted LVM). > After shutting it down yesterday, it did not let me unlock the encrypted disk > this morning. > > I already found the post from September 2012 in the mailing list, but it did not > exactly match my case (everything looks fine, not overwritten by SWAP data) > > > Header Information looks OK to me: > > # cryptsetup luksDump /dev/sda2 > LUKS header information for /dev/sda2 > > Version: 1 > Cipher name: aes > Cipher mode: cbc-essiv:sha256 > Hash spec: sha1 > Payload offset: 2056 > MK bits: 256 > MK digest: 53 44 c2 4d b0 9e c5 73 ef fa d7 12 4f dd f0 75 64 3b 88 ad > MK salt: 50 5f a9 69 21 6e 21 ac db 09 bd 79 b0 9b 9b 1e > 14 2a 5d e4 46 2b 4d 9c 49 e3 9f 7d f9 d7 64 84 > MK iterations: 10 > UUID: b89fe8ad-3aea-4f27-9448-06e75fd8a05a > > Key Slot 0: ENABLED > Iterations: 75899 > Salt: 2d 2b 66 4c 57 eb ff e7 7f 63 14 8f c5 3b 6b aa > 38 53 2d 52 52 b6 d9 cc 84 b0 1a 11 bd cf 88 70 > 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 > > > Looking closer to the header (exported to file via luksHeaderBackup), right > after the initial information also shown by luksDump up to address 0x1000 (first > keyslot) is filled with zeroes, from 0x1000 until the end of the file random > data with no ASCII that would indicate files (e.g. header informations) or a > partition table. > > The key slot checker though, gives me this output: > > > ./chk_luks_keyslots /home/r4pt0r/notebook/luksheader.img > > Sectors with entropy below threshold (0.850000): > > Keyslot 0: start: 0x1000 > position: 0x10000 entropy: 0.625023 That is far too low. Your key-slot has been compromised. Have a look specifically at offset 0x10000, the problem seems to be only in the 512 bytes starting there. You can use option -v to get a hex-dump of that sector. > Keyslot 1: start: 0x21000 > keyslot not in use > > Keyslot 2: start: 0x41000 > keyslot not in use > > Keyslot 3: start: 0x61000 > keyslot not in use > > Keyslot 4: start: 0x81000 > keyslot not in use > > Keyslot 5: start: 0xa1000 > keyslot not in use > > Keyslot 6: start: 0xc1000 > keyslot not in use > > Keyslot 7: start: 0xe1000 > keyslot not in use > > > > So the entropy seems to be too low? But where does the address 0x10000 come > from? shouldn't the key start at 0x1000 similar to its slot? > > > I HAD an backup of the header on USB stick - the Notebook was set up around 3-4 > years ago but i really found my old backup-stick (32MB) where also gpg-keys and > other small files were backed up. > BUT: the stick seems to be broken :( It's not recognized by any PC and the LED > doesn't light up... > > > > As the Notebook is usually put to sleep-mode I really can't remember what > updates were installed since the last reboot. > > > > Is there any possibility the key is not damaged and data can be recovered? No. Sorry. Maybe professional data recovery for the stick? The only thing without header backup is to find out what actually did the damage. Interesting in its own right, for prevention. Please post your findings here! 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 ---- One of the painful things about our time is that those who feel certainty are stupid, and those with any imagination and understanding are filled with doubt and indecision. -- Bertrand Russell ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [dm-crypt] No key available for this passphrase 2013-01-25 19:40 ` Arno Wagner @ 2013-01-25 19:57 ` Sebastian 2013-01-25 21:50 ` Arno Wagner 0 siblings, 1 reply; 25+ messages in thread From: Sebastian @ 2013-01-25 19:57 UTC (permalink / raw) To: dm-crypt Arno Wagner <arno@...> writes: > That is far too low. Your key-slot has been compromised. > Have a look specifically at offset 0x10000, the problem seems > to be only in the 512 bytes starting there. > > You can use option -v to get a hex-dump of that sector. > Well, it could have come to my mind to look at this address... Offset 0x10000: 0000000 gpt LUKS�� ext4dev extended linux-swap(v1) linux-swap(new) linux-swap(v0) linux-swap(old) hfs hfs+ ReIsEr4 LABELONE LVM2 _BHRfS_M - The file system is damaged linux-swap ufs create new %1 file system udevsettle udevsettle --timeout= udevadm settle --timeout= set partition type on %1 new partition type: %1 using libparted shrink file system grow file system resize file system delete partition Unable to find mount point ====================== libparted : ^(/[^ ]+) create empty partition path: %1 calW How on earth did that end up here and what could have caused it? After this it looks perfectly random again... ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [dm-crypt] No key available for this passphrase 2013-01-25 19:57 ` Sebastian @ 2013-01-25 21:50 ` Arno Wagner 2013-01-26 10:15 ` Sebastian 0 siblings, 1 reply; 25+ messages in thread From: Arno Wagner @ 2013-01-25 21:50 UTC (permalink / raw) To: dm-crypt On Fri, Jan 25, 2013 at 07:57:59PM +0000, Sebastian wrote: > Arno Wagner <arno@...> writes: > > > That is far too low. Your key-slot has been compromised. > > Have a look specifically at offset 0x10000, the problem seems > > to be only in the 512 bytes starting there. > > > > You can use option -v to get a hex-dump of that sector. > > Well, it could have come to my mind to look at this address... > > Offset 0x10000: > > 0000000 gpt LUKS�� ext4dev extended linux-swap(v1) linux-swap(new) > linux-swap(v0) linux-swap(old) hfs hfs+ ReIsEr4 LABELONE LVM2 _BHRfS_M > - The file system is damaged linux-swap ufs create new %1 file system udevsettle > udevsettle --timeout= udevadm settle --timeout= set partition type on %1 new > partition type: %1 using libparted shrink file system grow file system resize > file system delete partition Unable to find mount point ====================== > libparted : ^(/[^ ]+) create empty partition path: %1 calW Urks. Looks like a fragment from a menu or script? > How on earth did that end up here and what could have caused it? No idea. > After this it looks perfectly random again... As expected. The entropy-test is pretty sensitive. 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 ---- One of the painful things about our time is that those who feel certainty are stupid, and those with any imagination and understanding are filled with doubt and indecision. -- Bertrand Russell ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [dm-crypt] No key available for this passphrase 2013-01-25 21:50 ` Arno Wagner @ 2013-01-26 10:15 ` Sebastian 2013-01-26 17:41 ` Arno Wagner 0 siblings, 1 reply; 25+ messages in thread From: Sebastian @ 2013-01-26 10:15 UTC (permalink / raw) To: dm-crypt Sorry to bother again, but I'm trying to understand the whole processing of keys/password/masterkey within the LUKS mechanism when unlocking/decrypting the disk. I'm trying to understand it by using fugure 5 in this paper: http://wiki.cryptsetup.googlecode.com/git/LUKS-standard/on-disk-format.pdf Lets use my header as example (it's useless now anyways...) LUKS header information for /dev/sda2 Version: 1 Cipher name: aes Cipher mode: cbc-essiv:sha256 Hash spec: sha1 Payload offset: 2056 MK bits: 256 MK digest: 53 44 c2 4d b0 9e c5 73 ef fa d7 12 4f dd f0 75 64 3b 88 ad MK salt: 50 5f a9 69 21 6e 21 ac db 09 bd 79 b0 9b 9b 1e 14 2a 5d e4 46 2b 4d 9c 49 e3 9f 7d f9 d7 64 84 MK iterations: 10 UUID: b89fe8ad-3aea-4f27-9448-06e75fd8a05a Key Slot 0: ENABLED Iterations: 75899 Salt: 2d 2b 66 4c 57 eb ff e7 7f 63 14 8f c5 3b 6b aa 38 53 2d 52 52 b6 d9 cc 84 b0 1a 11 bd cf 88 70 Key material offset: 8 AF stripes: 4000 So when I enter the Password, it is processed by PBKDF2: pwdPBKDF2ed = PBKDF2 ( entered password, Salt for Key Slot 0 as given by header (2d 2b 66 4c ....), iteration-count (=75899), MasterKey lenth (256 bits) ) Am I correct about MK-lenght = MK bits? Then it reads the encrypted key aka payload: encryptedKey = data from "payload offset (sectors*size)" * "key leghth" -> offset 8 sectors * 512 byte = 4096 = 0x1000 key lenght = 4000 * original key lenght of the master key (256bit) that would be 128000 byte -> address 0x1000 + 128 000 byte = address 0x20400 correct? so "encryptedKey" = data from 0x1000 - 0x20400 (including 512 of crap from 0x10000 in my case...) now we put those 2 together and add some magic: splitKey = decrypt ( use aes/cbc-essiv:sha256 algorithm, pwd-PBKDF2ed calculated first by entered password, encrypted key data read from 0x1000 - 0x20400, "encrypted" ??? ) what is "encrypted"? The comment "content lenght" for it confuses me even more... With this splitKey we now create a checksum: masterKeyCandidate = AFmerge ( splitKey (ft. magic(TM) ), masterKeyLength (256), ks-stripes (4000) ) And process the checksum to compare with the MasterkeyChecksum from header: PBKDF2 ( masterKeyCandidate, phdr.mk-digest-salt ( 50 5f a9 69 21 ....), phdr.mk-digest-iter (10), LUKS_DIGEST_SIZE (20) ) if this processed Checksum is equal to the MK digest from header (53 44 c2 4d b0 9e c5 73 ef fa d7 12 4f dd f0 75 64 3b 88 ad ) the partition gets unlocked. Oh, and just hypothetical: If I would write a script to replace the broken 512 bits of the "encryptedKey" sequential from 00 00 00... up to FF FF FF... values, we would have 512^255 possible combinations. Lets assume we can try 1000 combinations per second in one process (I have no idea whether this is realistic) and also assume we have a 8-core system available for running 8 processes, starting at different offsets, it would still take 2,896966378463778741e+679 years.... (OK, some factor for mathematical probability when starting at 8 offsets will be added, but i think it's negligible...) Well, until theres a way to travel near speed of light to make use of time dilatation, the data is gone forever ;) So i'm still grep-ing the disks of my network-fileserver, maybe i had another backup of the header... Lesson learned, new drives for the fileserver ordered so i can backup more complete and more often... ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [dm-crypt] No key available for this passphrase 2013-01-26 10:15 ` Sebastian @ 2013-01-26 17:41 ` Arno Wagner 2013-01-27 8:42 ` Sebastian 0 siblings, 1 reply; 25+ messages in thread From: Arno Wagner @ 2013-01-26 17:41 UTC (permalink / raw) To: dm-crypt On Sat, Jan 26, 2013 at 10:15:16AM +0000, Sebastian wrote: > Sorry to bother again, but I'm trying to understand the whole processing Don't worry, just ask. If it is redundant or documented, we will tell you were to look. > of keys/password/masterkey within the LUKS mechanism when > unlocking/decrypting the disk. > I'm trying to understand it by using fugure 5 in this paper: > http://wiki.cryptsetup.googlecode.com/git/LUKS-standard/on-disk-format.pdf > > > Lets use my header as example (it's useless now anyways...) > > LUKS header information for /dev/sda2 > > Version: 1 > Cipher name: aes > Cipher mode: cbc-essiv:sha256 > Hash spec: sha1 > Payload offset: 2056 > MK bits: 256 > MK digest: 53 44 c2 4d b0 9e c5 73 ef fa d7 12 4f dd f0 75 64 3b 88 ad > MK salt: 50 5f a9 69 21 6e 21 ac db 09 bd 79 b0 9b 9b 1e > 14 2a 5d e4 46 2b 4d 9c 49 e3 9f 7d f9 d7 64 84 > MK iterations: 10 > UUID: b89fe8ad-3aea-4f27-9448-06e75fd8a05a > > Key Slot 0: ENABLED > Iterations: 75899 > Salt: 2d 2b 66 4c 57 eb ff e7 7f 63 14 8f c5 3b 6b aa > 38 53 2d 52 52 b6 d9 cc 84 b0 1a 11 bd cf 88 70 > Key material offset: 8 > AF stripes: 4000 > > > > > So when I enter the Password, it is processed by PBKDF2: > > pwdPBKDF2ed = PBKDF2 ( > entered password, > Salt for Key Slot 0 as given by header (2d 2b 66 4c ....), > iteration-count (=75899), > MasterKey lenth (256 bits) > ) Yes. > Am I correct about MK-lenght = MK bits? Yes. But note that for XTS mode, the mode and the cipher each get half of the master key. > > Then it reads the encrypted key aka payload: > > encryptedKey = data from "payload offset (sectors*size)" * "key leghth" > -> offset 8 sectors * 512 byte = 4096 = 0x1000 Yes, for the 1st slot. > key lenght = 4000 * original key lenght of the master key (256bit) > that would be 128000 byte -> address 0x1000 + 128 000 byte = address 0x20400 > correct? Yes, again 1st slot. > so "encryptedKey" = data from 0x1000 - 0x20400 (including 512 of crap from > 0x10000 in my case...) Yes. > now we put those 2 together and add some magic: > > splitKey = decrypt ( > use aes/cbc-essiv:sha256 algorithm, > pwd-PBKDF2ed calculated first by entered password, > encrypted key data read from 0x1000 - 0x20400, > "encrypted" ??? > ) > > what is "encrypted"? The comment "content lenght" > for it confuses me even more... Now I am starting to have to look this up as well ;-) If you just AF-split the MK, everybody can recover it, as long as all bits are intact. The non-encrypted AF-split MK (spkitKey in Fig. 4/5) is still the MK, but represented in a "blown-up" form. Hence it is stored encrypted just the same as data in the data area gets encrypted later. The "encrypted" (content length) parameter just tells the decrypot function on how much data passed by reference in "encryptedKey" here, it is supposed to work, i.e. it is just the keyslot-lenght. Figure 5 is ommiting some details and has some fuzzyness, don't let it confuse you. The decryption in Figure 5 is exactly the reverse of the encrypt in Figure 4. > With this splitKey we now create a checksum: > masterKeyCandidate = AFmerge ( > splitKey (ft. magic(TM) ), > masterKeyLength (256), > ks-stripes (4000) > ) Yes. > And process the checksum to compare with the MasterkeyChecksum from header: > PBKDF2 ( > masterKeyCandidate, > phdr.mk-digest-salt ( 50 5f a9 69 21 ....), > phdr.mk-digest-iter (10), > LUKS_DIGEST_SIZE (20) > ) Yes. The PBKDF2 iteration is necessary as otherwise the master-key might be brute-forced using this checksum. > if this processed Checksum is equal to the MK digest from header (53 44 c2 4d b0 > 9e c5 73 ef fa d7 12 4f dd f0 75 64 3b 88 ad ) the partition gets unlocked. Yes. Otherwise, try again with next key-slot. > > > Oh, and just hypothetical: > > If I would write a script to replace the broken 512 bits of the > "encryptedKey" sequential from 00 00 00... up to FF FF FF... > values, we would have 512^255 possible combinations. 256^512. It is a bit more, not that it matters ;-) > Lets assume we can try 1000 combinations per second in one process > (I have no idea whether this is realistic) Depends on your hardware and the hardware the LUKS header was created on. The iterations are selected so that unlocking one key-slot takes 0.25 sec. (The master key needs less iteration than passphrases, as it is high-quality random material.) > and also assume we have a 8-core system > available for running 8 processes, starting at different offsets, That gives you 32 keys/second. > it would still take 2,896966378463778741e+679 years.... (OK, some > factor for mathematical > probability when starting at 8 offsets will be added, but i think it's > negligible...) It is a factor of 2. The expected number of tries is that you have to search half the key-space. This takes then 5.4*10^1223 years. (With your 512^256 still 1.9*10^684 years, so your math is ok.) > Well, until theres a way to travel near speed of light to make use of time > dilatation, the data is gone forever ;) Don't also foget that a typical CPU only has a lifetime of 30 years before it breaks down... > So i'm still grep-ing the disks of my network-fileserver, > maybe i had another backup of the header... Lesson learned, > new drives for the fileserver ordered so > i can backup more complete and more often... Second lesson: Flash-keys are unsuitable for long-term storage (has to tell that one customer already that wanted to store an important master key that way. Fortunately they asked us first...) Here is a way for reliable long-term storage of small anounts of data: Print it with a laser-printer as OCR-A/B on good paper. Adding per-line checksums might be a good idea. Or print it as a sequence of QR codes - checksums and error correction already included. The other oprion is to store it in multiple locations and check the date regularly. 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 ---- One of the painful things about our time is that those who feel certainty are stupid, and those with any imagination and understanding are filled with doubt and indecision. -- Bertrand Russell ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [dm-crypt] No key available for this passphrase 2013-01-26 17:41 ` Arno Wagner @ 2013-01-27 8:42 ` Sebastian 2013-01-28 23:46 ` .. ink .. 0 siblings, 1 reply; 25+ messages in thread From: Sebastian @ 2013-01-27 8:42 UTC (permalink / raw) To: dm-crypt Arno Wagner <arno@...> writes: > > Second lesson: Flash-keys are unsuitable for long-term > storage (has to tell that one customer already that wanted > to store an important master key that way. Fortunately they > asked us first...) > > Here is a way for reliable long-term storage of small anounts > of data: > Print it with a laser-printer as OCR-A/B on good paper. > Adding per-line checksums might be a good idea. > Or print it as a sequence of QR codes - checksums and > error correction already included. > > The other oprion is to store it in multiple locations and > check the date regularly. > > Arno I like the idea of printing it as QR-code, never thought of using QR-Codes for backups ;) I will consider it for the ne setup! Should be also usable for gpg-keys... Another idea I had yesterday evening: I'm using a small ramdisk on my normal PC for playing minecraft - it meanwhile has a rather blown-up code and writes frequently to disk, causing slower machines to "hickup" every ~3 seconds. increasing read/write speed by using a ramdisk eliminates these symptoms. I use a small shellscript for initiating the ramdisk, cloning the data and syncing it. So, why not use such a mechanism (to ramdisk or normal disk) for backing up the header on boot time, and on shutdown comparing the backup with the current header. If equal -> everything is fine. If not - prompt either to restore it or leave it (when adde a new key e.g.), maybe even with a "diff"-output. It won't replace the real backup(s), but will give a little more failure tolerance plus a warning on shutdown IF anything went wrong with the header, so e.g. when on travel far away from backups you could restore the header. As the backup won't contain anything else than the header already does, I don't think it adds vulnerability to the system. If anyone gets access to the running system he could gain access to the header (and the key in the memory!) anyways. I think i will give this a try on the new setup on my Notebook. I can post the script here at the mailing list (it will be only a shellscript - my C has never evolved far over "hello world" ;) ), but a function like this or any other mechanism of header-protection would be nice to see as standard for LUKS. Especially because the first keyslot is so likely to be corrupted by partition managers (should be aroud the offset of keyslot 0 where they start to dump their data?). Sebastian ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [dm-crypt] No key available for this passphrase 2013-01-27 8:42 ` Sebastian @ 2013-01-28 23:46 ` .. ink .. 2013-01-29 2:39 ` Arno Wagner 0 siblings, 1 reply; 25+ messages in thread From: .. ink .. @ 2013-01-28 23:46 UTC (permalink / raw) To: dm-crypt [-- Attachment #1: Type: text/plain, Size: 588 bytes --] [..] > but a function like this or any other > mechanism of header-protection would be nice to see as standard for LUKS. > Especially because the first keyslot is so likely to be corrupted by > partition > managers (should be aroud the offset of keyslot 0 where they start to dump > their > data?). > > has there been any study to find out which ones of the keyslots is most likely to get corrupted accidentally by various tools? will adding keys from the last slot going backwards add some protection from keys being inaccessible due to accidental header corruption by various tools? [-- Attachment #2: Type: text/html, Size: 954 bytes --] ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [dm-crypt] No key available for this passphrase 2013-01-28 23:46 ` .. ink .. @ 2013-01-29 2:39 ` Arno Wagner 2013-01-31 13:43 ` Sebastian 0 siblings, 1 reply; 25+ messages in thread From: Arno Wagner @ 2013-01-29 2:39 UTC (permalink / raw) To: dm-crypt On Mon, Jan 28, 2013 at 06:46:53PM -0500, .. ink .. wrote: > [..] > > > but a function like this or any other > > mechanism of header-protection would be nice to see as standard for LUKS. > > Especially because the first keyslot is so likely to be corrupted by > > partition > > managers (should be aroud the offset of keyslot 0 where they start to dump > > their > > data?). > > > > > has there been any study to find out which ones of the keyslots is most > likely to get corrupted accidentally by various tools? I do not think there is enough data. And there is the additional problem that corruption in others than slot 0 will not be noticed by most users. You are welcome to search the mai,ing-list archives and generate a statistic, of course. > will adding keys from the last slot going backwards add some protection > from keys being inaccessible due to accidental header corruption by various > tools? I think most tools will kill the header. After that, damage to key-slots does not matter much, as the header carries the all-iportant salts. While it does happen occasionally that just a key-slot gets corrupted, it is rare. The keyslot-checker I wrote was not due to a dire need, but because I hacked together a version in Python that read the disk directly in a 2-3 hours, and then Milan (rightfully) asked me to do it right. Provided entertainment for me for a weekend and an opportunity to look at libcryptsetup. I think we may have seen someting like 5-6 cases altogether in the last few years. No idea how many people managed to kill their LUKS containers, but never reported it on the list. And anyways, disks do die, so data-backup is mandatory even for encrypted volumes. See the FAQ for some suggestions. 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 ---- One of the painful things about our time is that those who feel certainty are stupid, and those with any imagination and understanding are filled with doubt and indecision. -- Bertrand Russell ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [dm-crypt] No key available for this passphrase 2013-01-29 2:39 ` Arno Wagner @ 2013-01-31 13:43 ` Sebastian 2013-01-31 17:48 ` .. ink .. 0 siblings, 1 reply; 25+ messages in thread From: Sebastian @ 2013-01-31 13:43 UTC (permalink / raw) To: dm-crypt Arno Wagner <arno@...> writes: > > On Mon, Jan 28, 2013 at 06:46:53PM -0500, .. ink .. wrote: > > [..] > > > > > but a function like this or any other > > > mechanism of header-protection would be nice to see as standard for LUKS. > > > Especially because the first keyslot is so likely to be corrupted by > > > partition > > > managers (should be aroud the offset of keyslot 0 where they start to dump > > > their > > > data?). > > > > > > > > has there been any study to find out which ones of the keyslots is most > > likely to get corrupted accidentally by various tools? > > I do not think there is enough data. And there is the additional > problem that corruption in others than slot 0 will not be noticed > by most users. You are welcome to search the mai,ing-list archives > and generate a statistic, of course. > [...] As soon as I received my new harddrive for the notebook (the one delivered constantly makes fast scratching noises at idle...), i will start to write a small script that backups the header on the disk and frequently compares this backup to the disk/partition header. If changes are detected it will give a warning plus the option to restore the header. Well - thats the plan. Will see what functions will make it to the script or will be added while writing it. It will be only a shellscript ( need glasses - I can't C very good ;) ), but i will post it here (maybe new thread) as soon as it is working. Sebastian ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [dm-crypt] No key available for this passphrase 2013-01-31 13:43 ` Sebastian @ 2013-01-31 17:48 ` .. ink .. 0 siblings, 0 replies; 25+ messages in thread From: .. ink .. @ 2013-01-31 17:48 UTC (permalink / raw) To: Sebastian; +Cc: dm-crypt [-- Attachment #1: Type: text/plain, Size: 1623 bytes --] > As soon as I received my new harddrive for the notebook (the one delivered > constantly makes fast scratching noises at idle...), i will start to write > a > small script that backups the header on the disk and frequently compares > this > backup to the disk/partition header. If changes are detected it will give a > warning plus the option to restore the header. > Well - thats the plan. Will see what functions will make it to the script > or > will be added while writing it. > > It will be only a shellscript ( need glasses - I can't C very good ;) ), > but i > will post it here (maybe new thread) as soon as it is working. > > just added a functionality in my tool to check if a header on a device matches a header in back up file. A test of the functionality is below. 1. Get a header backup [ink@mtz ~]$ zuluCrypt-cli -B -d /dev/sdc1 -f headerbackup.luks SUCCESS: header saved successfully 2. Check if the header on the device matches the one in a header file [ink@mtz ~]$ zuluCrypt-cli -H -d /dev/sdc1 -f headerbackup.luks header backup match the one on the device 3. Add a key to a volume to change the header. [ink@mtz ~]$ zuluCrypt-cli -a -d /dev/sdc1 -y xxx -l zzz SUCCESS: key added successfully 4.Check if the header on the device matches the one in a header file [ink@mtz ~]$ zuluCrypt-cli -H -d /dev/sdc1 -f headerbackup.luks header backup does not match the one on the device So far,it seem to be working as expected. Your shell script will be much simpler if you use my tool :-) The commit is at : http://code.google.com/p/zulucrypt/source/detail?r=ee03cb7b3c0d698fb68de0591a192ce06009c550 [-- Attachment #2: Type: text/html, Size: 2438 bytes --] ^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2013-01-31 17:49 UTC | newest] Thread overview: 25+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-09-08 9:03 [dm-crypt] No key available for this passphrase Marcos 2012-09-08 13:35 ` Arno Wagner 2012-09-08 18:47 ` Marcos 2012-09-08 20:02 ` Arno Wagner 2012-09-08 20:51 ` Marcos 2012-09-08 22:47 ` Arno Wagner 2012-09-09 12:53 ` Marcos 2012-09-09 13:49 ` Arno Wagner 2012-09-09 14:06 ` Marcos 2012-09-08 23:16 ` [dm-crypt] Re2: " Arno Wagner 2012-09-09 12:58 ` Marcos 2012-09-08 22:45 ` [dm-crypt] " Matthias Schniedermeyer 2012-09-09 8:45 ` Milan Broz 2012-09-09 13:42 ` Arno Wagner -- strict thread matches above, loose matches on Subject: below -- 2013-01-25 17:53 Sebastian 2013-01-25 19:40 ` Arno Wagner 2013-01-25 19:57 ` Sebastian 2013-01-25 21:50 ` Arno Wagner 2013-01-26 10:15 ` Sebastian 2013-01-26 17:41 ` Arno Wagner 2013-01-27 8:42 ` Sebastian 2013-01-28 23:46 ` .. ink .. 2013-01-29 2:39 ` Arno Wagner 2013-01-31 13:43 ` Sebastian 2013-01-31 17:48 ` .. ink ..
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.