yeah... you are right! Thanks for the clarification. I've been meaning to read the Stegotorus paper soon.
Cheers!
David
On Mon, Nov 18, 2013 at 9:24 AM, Zack Weinberg zackw@panix.com wrote:
On Mon, Nov 18, 2013 at 10:47 AM, David Stainton dstainton415@gmail.com wrote:
Super-simple framing protocols often fall victim to attacks in which the adversary messes with the length in the frame header. See, for example, "Plaintext Recovery Attacks Against SSH": http://www.isg.rhul.ac.uk/~kp/SandPfinal.pdf
Over Tor it won't be a problem because Tor is authenticated.
I think that's an oversimplistic way of looking at the problem, but you're mostly right.
Suppose that your message framing is just
len (4 bytes plaintext) | LEN bytes of cipher text including higher level MAC | ...
If an active MITM flips bits in the length field, you will feed the wrong number of bytes to the decryptor and the MAC check will fail. Moreover, this is an *unrecoverable* failure condition: there's no way for you to get back in sync with the other end. You have to drop the connection, and the other side has to respond to a connection drop in a sensible fashion. (I wouldn't recommend trying to reconnect and retransmit the queue - rather, propagate the failure up to Tor.) But, because the length field is plaintext, there is no decryption oracle; the adversary can't trick you into decrypting something that's not a length field and treating the result as a length field. I think this is probably acceptable for obfsK, which is just supposed to be different from anything recognizable.
If you want all-bytes-on-the-wire-indistinguishable-from-randomness, that is considerably harder -- a great deal of the complexity of the "chopper" of https://hacks.owlfolio.org/pubs/2012-stegotorus.pdf is in service of being able to encrypt the length field without exposing a decryption oracle. Note that I no longer think that design is sound, but it will still give you an idea of what it takes.
zw _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev