forwarding the email to the mailing list because my initial reply was sent privately( again,should pay more attention to where i send my emails :-) )
On Mon, Apr 2, 2012 at 2:15 PM, .. ink .. <mhogomchungu@xxxxxxxxx> wrote:
this part perfectly explains what i was observing.- for LUKS, if keyslot status is in some unexpected state
(either not active or active) - well, this one can be caused by
partial header corruption.
(This check should be perhaps in crypt_load as well...
Anyway, slot with invalid status is the same like non-active slot
- cannot be used for unlocking.
Milan
did another test:
[ink@mtz ~]$ ./test luks1 256 yyyyyyyyyyyyyyyyyyyy
[ink@mtz ~]$ zuluCrypt-cli -b -d luks1
12100000
[ink@mtz ~]$./test luks1 256 yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy
[ink@mtz ~]$ zuluCrypt-cli -b -d luks1
device "luks1" is not a luks device
the test program is at the end of the email.
so currently,it is possible to corrupt the header in a way that crypt_load() will not detect the corruption but but crypt_keyslot_status() will if the minor corruption is in a key slot it run on.
This explains why i couldnt seem to trigger the invalid key error that was being reported.My corruption wasnt big enough.
the luks disk specification says key slot field in the header takes 48 units of length(48 bytes??) and is of data type "key slot". what is data type "key slot"? i am asking purest as a matter of couriosity and not because i want to parse the header in any shape or form.
int main( int argc,char * argv[] )
{
const char * path = argv[1];
size_t offset = atoi(argv[2]);
const char * data = ""> size_t len = strlen(data);
int i = open(path,O_WRONLY);
lseek(i,offset,SEEK_SET);
write(i,data,len);
close(i);
return 0 ;
}
_______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
