[dm-crypt] No key available for this passphrase

[dm-crypt] No key available for this passphrase

[Marcos]

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/

Re: [dm-crypt] No key available for this passphrase

[Arno Wagner]

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 

Re: [dm-crypt] No key available for this passphrase

[Marcos]

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/

Re: [dm-crypt] No key available for this passphrase

[Arno Wagner]

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 

Re: [dm-crypt] No key available for this passphrase

[Marcos]

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/

Re: [dm-crypt] No key available for this passphrase

[Matthias Schniedermeyer]

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.

Re: [dm-crypt] No key available for this passphrase

[Arno Wagner]

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 

[dm-crypt] Re2: No key available for this passphrase

[Arno Wagner]

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 

Re: [dm-crypt] No key available for this passphrase

[Milan Broz]

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

Re: [dm-crypt] No key available for this passphrase

[Marcos]

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/

Re: [dm-crypt] Re2: No key available for this passphrase

[Marcos]

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/

Re: [dm-crypt] No key available for this passphrase

[Arno Wagner]

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 

Re: [dm-crypt] No key available for this passphrase

[Arno Wagner]

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 

Re: [dm-crypt] No key available for this passphrase

[Marcos]

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/