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 <[email protected]> wrote: > On Mon, Nov 18, 2013 at 10:47 AM, David Stainton <[email protected]> > 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 > [email protected] > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev _______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
