Sorry to bother again, but I'm trying to understand the whole processing of keys/password/masterkey within the LUKS mechanism when unlocking/decrypting the disk. I'm trying to understand it by using fugure 5 in this paper: http://wiki.cryptsetup.googlecode.com/git/LUKS-standard/on-disk-format.pdf Lets use my header as example (it's useless now anyways...) LUKS header information for /dev/sda2 Version: 1 Cipher name: aes Cipher mode: cbc-essiv:sha256 Hash spec: sha1 Payload offset: 2056 MK bits: 256 MK digest: 53 44 c2 4d b0 9e c5 73 ef fa d7 12 4f dd f0 75 64 3b 88 ad MK salt: 50 5f a9 69 21 6e 21 ac db 09 bd 79 b0 9b 9b 1e 14 2a 5d e4 46 2b 4d 9c 49 e3 9f 7d f9 d7 64 84 MK iterations: 10 UUID: b89fe8ad-3aea-4f27-9448-06e75fd8a05a Key Slot 0: ENABLED Iterations: 75899 Salt: 2d 2b 66 4c 57 eb ff e7 7f 63 14 8f c5 3b 6b aa 38 53 2d 52 52 b6 d9 cc 84 b0 1a 11 bd cf 88 70 Key material offset: 8 AF stripes: 4000 So when I enter the Password, it is processed by PBKDF2: pwdPBKDF2ed = PBKDF2 ( entered password, Salt for Key Slot 0 as given by header (2d 2b 66 4c ....), iteration-count (=75899), MasterKey lenth (256 bits) ) Am I correct about MK-lenght = MK bits? Then it reads the encrypted key aka payload: encryptedKey = data from "payload offset (sectors*size)" * "key leghth" -> offset 8 sectors * 512 byte = 4096 = 0x1000 key lenght = 4000 * original key lenght of the master key (256bit) that would be 128000 byte -> address 0x1000 + 128 000 byte = address 0x20400 correct? so "encryptedKey" = data from 0x1000 - 0x20400 (including 512 of crap from 0x10000 in my case...) now we put those 2 together and add some magic: splitKey = decrypt ( use aes/cbc-essiv:sha256 algorithm, pwd-PBKDF2ed calculated first by entered password, encrypted key data read from 0x1000 - 0x20400, "encrypted" ??? ) what is "encrypted"? The comment "content lenght" for it confuses me even more... With this splitKey we now create a checksum: masterKeyCandidate = AFmerge ( splitKey (ft. magic(TM) ), masterKeyLength (256), ks-stripes (4000) ) And process the checksum to compare with the MasterkeyChecksum from header: PBKDF2 ( masterKeyCandidate, phdr.mk-digest-salt ( 50 5f a9 69 21 ....), phdr.mk-digest-iter (10), LUKS_DIGEST_SIZE (20) ) if this processed Checksum is equal to the MK digest from header (53 44 c2 4d b0 9e c5 73 ef fa d7 12 4f dd f0 75 64 3b 88 ad ) the partition gets unlocked. Oh, and just hypothetical: If I would write a script to replace the broken 512 bits of the "encryptedKey" sequential from 00 00 00... up to FF FF FF... values, we would have 512^255 possible combinations. Lets assume we can try 1000 combinations per second in one process (I have no idea whether this is realistic) and also assume we have a 8-core system available for running 8 processes, starting at different offsets, it would still take 2,896966378463778741e+679 years.... (OK, some factor for mathematical probability when starting at 8 offsets will be added, but i think it's negligible...) Well, until theres a way to travel near speed of light to make use of time dilatation, the data is gone forever ;) So i'm still grep-ing the disks of my network-fileserver, maybe i had another backup of the header... Lesson learned, new drives for the fileserver ordered so i can backup more complete and more often... _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
