[dm-crypt] what touches the LUKS header?

[epvdm@limpoc.com]

I'm trying to discover what happened to a Luks encrypted partition that's
become impossible to unlock following a reboot.  The partition is a md mirror 
of two disk partitions.  

I'm assuming that something has managed to corrupt the LUKS header, as trying 
to unlock gives "No key available with this passphrase." I'm quite confident 
the passphrase is correct, as it worked after a reboot a few days ago, and i'm 
irresponsibly consistent in my passphrase choices, sad to say. :)

I have a bunch of mirror copies of the partition and the luks header data on
all of them (from luksHeaderBackup) is identical. luksDump shows what looks 
like plausible data: 

Version:       	1
Cipher name:   	aes
Cipher mode:   	cbc-essiv:sha256
Hash spec:     	sha1
Payload offset:	1032
MK bits:       	128
MK digest:     	a4 5e 29 97 a6 01 0c c8 f7 be ad e2 75 18 19 07 0b a2 e9 cd 
MK salt:       	<...>
MK iterations: 	10
UUID:          	eab03b35-6945-4608-9ae3-14c4bda8c8df

Key Slot 0: ENABLED
	Iterations:         	250772
	Salt:               	<...>
	Key material offset:	8
	AF stripes:            	4000
Key Slot 1: DISABLED
...

All the necessary kernel modules, etc, are in place, as far as I can tell. 
Again, it was mounted and working until a recent crash and reboot. 

I'm wondering if the header area ever gets written to under normal operation
such that a crash could have left it corrupted, or if it's only written when
modifying keyslots, etc... 

There are other partitions on the disks which don't appear to have become
corrupted. My main suspect so far is that md had something to do with it, but
it seems odd that it'd selective corrupt a small area of disk that wouldn't
have been written recently, that's well off in the middle of the drive, and
not damage more widely. 

Naturally I'd be thrilled to find some way of recovering the data but I'm 
more concerned at the moment with finding out why it's suddenly stopped 
working in the first place. 

I don't believe corruption to other parts of the volume, outside of the header
area, could cause it to fail to unlock like this; is that correct? 

thanks, 
eric