Steve Crook <steve mixmin.net> Sorry for not replying to this as my spam detection was too severe. > 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.
Agreed: encrypted RSA data size depends on key size. > 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. The aim is a remailer cannot tell where it is in the chain (unless it's the exit) and the header HMAC is always calculated over 1024 bytes (there is always onion-packed data even if it's random rather than meaningful header and the HMAC is just to check it wasn't changed). In the case I think you mean where the full chain is used and the last 2 hops are 4096,1024 then 512 bytes of the input to the HMAC will be read from the message body. > 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. I was assuming since different keys are used nobody cares if the IV is shared. And the update to the IV is unintended - a buglet. If we were to make an incompatible change further things that might be done are: - potentially longer chains (someone has been complaining about the limit of 10 hops with large keys) - encrypt only an unpadded large random value under RSA and derive all other per-hop random values from it (Cryptography Engineering section 12.6) - drop 3DES I suspect incompatible changes are best reserved for a complete new scheme such as https://github.com/nmathewson/mixminion . ------------------------------------------------------------------------------ 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
