On Wed, Aug 20, 2014 at 11:59:49AM +0100, Steve Crook wrote: > Hi, > > I'm trying to code a Mixmaster client with compatibility to the new 1024 > Byte header format used in Mixmaster-3.0.2. I'd appreciate a little > help in understanding the process for producing the new header. > > As I understand it, the header format is:- > > Public key ID [ 16 bytes] > Length of RSA-encrypted data [ 1 byte ] > RSA-encrypted data [ 256/384/512 bytes ] > 3DES Session Key [ 24 bytes ] > Random HMAC Key [ 64 bytes ] > HMAC hash (Anti-tag) [ 32 bytes ] > HMAC hash (Body) [ 32 bytes ] > HMAC hash (328 Byte Enc Head) [ 32 bytes ] > AES Pre Key [ 32 bytes ] > ?Padding? > 3DES Initialization vector [ 8 bytes] > Encrypted header part [ 328 bytes] > Padding [ n bytes] > ----------------------------------------- > Total [ 1024 bytes] > > First question: Is the RSA-encrypted section always padded to 512 Bytes > or is it variable depending on the RSA key size? To put it another way, > is the position of the 3DES IV always 529 Bytes in, or is it floating?
After studying the mixmaster-3.0.2 code, I think I can answer some of these questions myself. For the above: No padding is applied to the RSA data so the subsequent fields are at variable positions within the header. > HMAC Anti-Tag:- > I believe this is a hash of the subsequent 512 Byte header *after > encryption*. This implies that the next header must already have been > encrypted using the 3DES Key and IV from the current 328 Byte component. > Also, what goes in here for an Exit type header? The field is populated with random data for an exit header. The Anti-tag is calculated on 2*512 Byte header blocks but in a scenario where the exit remailer uses a 1024bit key, there is only 512 Bytes of header data. I've not entirely sure how this scenario is handled. If the hmac is calculated on just the 512 Bytes of the exit header then a remailer can determine when it's the penultimate member of the chain. > HMAC Body:- > As above, to generate the HMAC Body, the body must already be encrypted > using the current 328 Byte block. > > HMAC 328:- > This is a hash of the 328 Byte block, *after* 3DES encryption. All the above HMACS are calculated after 3DES and AES encryption. > AES Pre Key:- > From the packet_layout document: > "The aes_pre_key is used together with HMAC-SHA256 to generate the 3 > AES keys for the body, future headers and the current header data of > size 328." > I'm struggling to understand this bit. Is this a salt that's used in > conjunction with the previous HMACs to generate three AES keys? Is > there an IV associated with each of them? The 3 keys and the IV are derived from an HMAC function on a static plaintext concatenated with the HMAC key. The static texts being: body-crypt tte-crypt header-crypt aes-iv There is a bug in the implementation of the AES encrypt/decrypt functions but it impacts both directions in an identical manner so they work together. The spec calls for an identical IV to be used in all three AES encrypt/decrypt functions but the implementation uses a unique IV for each. This happens because the OpenSSL CRYPTO_cfb128_encrypt function modifies the IV during each operation. It would probably be better to derive three IVs, one for each AES key but this would now break backward compatibility. Steve
signature.asc
Description: Digital signature
------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/
_______________________________________________ Mixmaster-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mixmaster-devel
