Re: No key available for this passphrase

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxx 
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 mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt


[Index of Archives]     [Device Mapper Devel]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux