[dm-crypt] No key available for this passphrase

Marcos marcos at tenak.net
Sat Sep 8 22:51:29 CEST 2012


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/


More information about the dm-crypt mailing list