On Sat, Aug 23, 2014 at 06:15:57PM +0100, [email protected] wrote: > Steve Crook <steve mixmin.net> > > Sorry for not replying to this as my spam detection was too severe. No problem, your comments in the code made it easy to decipher once I motivated myself to figure it out.
> > 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. Ah, that makes sense now, thanks. I will need to tweak my client implementation to handle that scenario. > > 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. It's generally considered bad to reuse an IV but, as you say, with different keys, I'm not sure if that matters. The changing IV doesn't matter in Mixmaster as it changes identically during encrypt and decrypt operations. It's more of a headache for writing other clients though: I'm trying to unpick the CRYPTO_cfb128_encrypt function in OpenSSL to figure out how the IV mutates so I can reproduce the behaviour. The writer of that function operates on a different level to me so progress is slow! :) > 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) Yes, I tried to avoid that debate! I think 10 hops is plenty. If you made it 20, somebody would want 30. :) > - encrypt only an unpadded large random value under RSA and derive all other > per-hop random values from it (Cryptography Engineering section 12.6) Or use a RSA to encrypt a single 3DES or AES key and put all the sensitive stuff in the encrypted header. > - drop 3DES Maybe replace that with AES and RSA with ECC. The second would save a shed-load of Bytes. > I suspect incompatible changes are best reserved for a complete new scheme > such as https://github.com/nmathewson/mixminion . I'd love to see mixminion revived. Unfortunately, while I can understand and, to some extent, implement the Mixmaster spec, the maths in Mixminion is beyond my grasp.
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
