On Sat, Jan 26, 2013 at 10:15:16AM +0000, Sebastian wrote: > Sorry to bother again, but I'm trying to understand the whole processing Don't worry, just ask. If it is redundant or documented, we will tell you were to look. > 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) > ) Yes. > Am I correct about MK-lenght = MK bits? Yes. But note that for XTS mode, the mode and the cipher each get half of the master key. > > Then it reads the encrypted key aka payload: > > encryptedKey = data from "payload offset (sectors*size)" * "key leghth" > -> offset 8 sectors * 512 byte = 4096 = 0x1000 Yes, for the 1st slot. > key lenght = 4000 * original key lenght of the master key (256bit) > that would be 128000 byte -> address 0x1000 + 128 000 byte = address 0x20400 > correct? Yes, again 1st slot. > so "encryptedKey" = data from 0x1000 - 0x20400 (including 512 of crap from > 0x10000 in my case...) Yes. > 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... Now I am starting to have to look this up as well ;-) If you just AF-split the MK, everybody can recover it, as long as all bits are intact. The non-encrypted AF-split MK (spkitKey in Fig. 4/5) is still the MK, but represented in a "blown-up" form. Hence it is stored encrypted just the same as data in the data area gets encrypted later. The "encrypted" (content length) parameter just tells the decrypot function on how much data passed by reference in "encryptedKey" here, it is supposed to work, i.e. it is just the keyslot-lenght. Figure 5 is ommiting some details and has some fuzzyness, don't let it confuse you. The decryption in Figure 5 is exactly the reverse of the encrypt in Figure 4. > With this splitKey we now create a checksum: > masterKeyCandidate = AFmerge ( > splitKey (ft. magic(TM) ), > masterKeyLength (256), > ks-stripes (4000) > ) Yes. > 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) > ) Yes. The PBKDF2 iteration is necessary as otherwise the master-key might be brute-forced using this checksum. > 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. Yes. Otherwise, try again with next key-slot. > > > 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. 256^512. It is a bit more, not that it matters ;-) > Lets assume we can try 1000 combinations per second in one process > (I have no idea whether this is realistic) Depends on your hardware and the hardware the LUKS header was created on. The iterations are selected so that unlocking one key-slot takes 0.25 sec. (The master key needs less iteration than passphrases, as it is high-quality random material.) > and also assume we have a 8-core system > available for running 8 processes, starting at different offsets, That gives you 32 keys/second. > 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...) It is a factor of 2. The expected number of tries is that you have to search half the key-space. This takes then 5.4*10^1223 years. (With your 512^256 still 1.9*10^684 years, so your math is ok.) > Well, until theres a way to travel near speed of light to make use of time > dilatation, the data is gone forever ;) Don't also foget that a typical CPU only has a lifetime of 30 years before it breaks down... > 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... Second lesson: Flash-keys are unsuitable for long-term storage (has to tell that one customer already that wanted to store an important master key that way. Fortunately they asked us first...) Here is a way for reliable long-term storage of small anounts of data: Print it with a laser-printer as OCR-A/B on good paper. Adding per-line checksums might be a good idea. Or print it as a sequence of QR codes - checksums and error correction already included. The other oprion is to store it in multiple locations and check the date regularly. Arno -- Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@xxxxxxxxxxx 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 _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
