Re: [tor-dev] obfsproxy buffering

[David Stainton <dstainton415@xxxxxxxxx>]

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