Re: [dm-crypt] Can't mount my LUKS crypted disk after kernel update / reboot

[Arno Wagner <arno@wagner.name>]

On Sun, Dec 16, 2012 at 07:11:22PM +0100, Philipp Durrer wrote:
> dmsetup table --showkeys
> truecrypt1_1: 0 204288 crypt serpent-xts-plain64
> 6194df1a929675daf3792880da3f36f79b819e7f4e42267e6f25deedd172a231a7bcfc84c0853c5413666fbadf93ea096f98cdf1944080859d3a88b6cd99c209
> 256 7:0 256
> truecrypt2: 0 10485248 crypt twofish-xts-plain64
> 36fee68d56029b9dfbe969a76f10c7f9db17ab4305e974e6affd128f1a57b58ccaa0e12bf13ee5e27f67e991222dd0c6ad8bfea9ab9b3ea053d90f8d50d81879
> 256 253:3 0
> truecrypt1_0: 0 204288 crypt twofish-xts-plain64
> e3200b4f4e95e99222cdcbcd70c75bf8ed14ae7993c4f00446437ba96939feb8ea9fa9d2724fb865bc05740253604e9024e82e8a392e2274150488f69cff23d6
> 256 253:0 0
> truecrypt1: 0 204288 crypt aes-xts-plain64
> db606af9d8f18fa7d78750765272d79c86eb1958aef7c835c6b6927aaef8f2bf1d5e964c6b0d6e0e32d812fac0d952245be1630b108a7d90310190509d78660b
> 256 253:1 0
> truecrypt2_0: 0 10485248 crypt aes-xts-plain64
> e574ef4dc7c75fbf56bb2f3520414c371fda1f4df8b54ceab2adf0409518df81537b6e7d7edbd46db493f00bd5cd2657d42f12e7f36f4addf9e83de0a9bd7f72
> 256 7:1 256
> stuff: 0 11664377856 crypt aes-xts-essiv:sha256
> 4c8bab80fd627b8f5bbff24d3f458d5555b19c340352c5f14f980227b157089b8d466ba555873ce8edb8dc101c96c8c0f96a1f79c2124076589c11a4f7453a7b
> 0 9:126 4096

Woah, stop! Or rather too late. Everybody in the internet now has
your master keys and can decrypt your devices!

> > So IMHO the problem is in MD layer, ext4, or in some unexpected device
> > rewrite during update or so.
> >
> 
> that's what I think aswell

It has to be. LUKS does nto decrypt is anything at all with it is
broken. Unlike plain dm-crypt that will happily decrypt with 
everything wrong and produce just random-looking stuff.

Now, if you look into the FAQ, item 6.12, you will see that the
satart of the md device has to be intact for decyption to happen.
Also, what superblock format did you use? 
"mdadm --examine <some raid component>" should tell you.
The idea is that if it is 1.1 or 1.2 then the md superblock
are also at the beginning. Overwrites typicallyt happen 
at the beginning, not somewhere in there,
 
Just to be sure: Does maybe the new kernel not support the
filesystem you are using? Maybe this is a module-loading
problem?

What you also can try is to specify an alternate superblock
for mount. The option for that is e.g. "sb=131072" (from the
man-page)

[...]
 
> 
> I did check the keyslot with the keyslot_checker in misc, did report that
> everything looks fine.
> Did aswell check the disk with hd tool and looks fine aswell all random
> data up to 0x20000 where data begins.
>
> If no other ideas come to mind until tomorrow I will reformat the disks I
> think.

Well, it would be nice to find out what caused this, but
I can understand that you do not want to invest too much more
time.

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