[dm-crypt] does luksDump guarantee header integrity?

[dm-crypt] does luksDump guarantee header integrity?

[hank]

Hi,

I accidentally "formatted" an encrypted partition with mkfs.nilfs2
(incl. -K option). Luckily mkfs.nilfs2 normally only overwrites data
after 1024 bytes from the start of the block device, so the LUKS header
should have remained intact.

luksDump does confirm that or at least it outputs something that looks
sane. However my passphrase is not accepted by luksOpen anymore ("no
matching key ..."). Now is the header corrupted or not? Can a header
somehow be partially corrupted so that it dumps fine but the keyslot has
a couple of bits flipped (even though I am not sure why mkfs.nilfs2
would cause some partial corruption like that).

Regards

hank

Re: [dm-crypt] does luksDump guarantee header integrity?

[Robert Nichols]

On 03/23/2013 12:38 AM, hank wrote:
> Hi,
>
> I accidentally "formatted" an encrypted partition with mkfs.nilfs2
> (incl. -K option). Luckily mkfs.nilfs2 normally only overwrites data
> after 1024 bytes from the start of the block device, so the LUKS header
> should have remained intact.

The LUKS header, including the key material, is roughly a half Megabyte
in size. The key material, expanded and broken up into 4000 stripes for
each key slot, follows the 592-byte LUKS partition header (PHDR). Your
accidental formatting left the parameters in the PHDR and the
descriptors for first 6 key slots untouched, but overwrote the actual
key material.  Without a backup of the entire ~.5MB LUKS header you
cannot obtain the master key, and your data is unrecoverable.

-- 
Bob Nichols     "NOSPAM" is really part of my email address.
                 Do NOT delete it.

Re: [dm-crypt] does luksDump guarantee header integrity?

[Arno Wagner]

On Sat, Mar 23, 2013 at 08:59:08AM -0500, Robert Nichols wrote:
> On 03/23/2013 12:38 AM, hank wrote:
> >Hi,
> >
> >I accidentally "formatted" an encrypted partition with mkfs.nilfs2
> >(incl. -K option). Luckily mkfs.nilfs2 normally only overwrites data
> >after 1024 bytes from the start of the block device, so the LUKS header
> >should have remained intact.
> 
> The LUKS header, including the key material, is roughly a half Megabyte
> in size. The key material, expanded and broken up into 4000 stripes for
> each key slot, follows the 592-byte LUKS partition header (PHDR). Your
> accidental formatting left the parameters in the PHDR and the
> descriptors for first 6 key slots untouched, but overwrote the actual
> key material.  Without a backup of the entire ~.5MB LUKS header you
> cannot obtain the master key, and your data is unrecoverable.

Unfortunately, that is accuirate. Just to be sure, you can run the
LUKS keyslot cheker included in the newer sources and found unter 
/cryptsetup-1.6.0/misc/keyslot_checker/. It has to be built separately
(just call "make" in its directory) after installing cryptsetuo
from the same package (or one that has the features the keyslot
checker needs). It will check each in-use keyslot for overwritten
areas. If there are any, that keyslot becomes unusable and 
unrecoverable.

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

Re: [dm-crypt] does luksDump guarantee header integrity?

[hank]

Interesting, thanks. I had a naive view of the keys being stored in the
slot 'descriptors'. Seems there is more science to that. -- Hank

On Sun, Mar 24, 2013, at 01:48 AM, Arno Wagner wrote:
> Unfortunately, that is accuirate. Just to be sure, you can run the
> LUKS keyslot cheker included in the newer sources and found unter 
> /cryptsetup-1.6.0/misc/keyslot_checker/. It has to be built separately
> (just call "make" in its directory) after installing cryptsetuo
> from the same package (or one that has the features the keyslot
> checker needs). It will check each in-use keyslot for overwritten
> areas. If there are any, that keyslot becomes unusable and 
> unrecoverable.