Re: [tor-dev] SkypeMorph

[George Kadianakis <desnacked@xxxxxxxxxx>]

Hooman <hmohajer@xxxxxxxxxxxxxxx> writes:

> On 12-03-28 06:57 PM, George Kadianakis wrote:
>> Hooman <hmohajer@xxxxxxxxxxxxxxx> writes:
>>> We called it SkypeMorph since we are still using the morphing
>>> matrix. Although, I personally believe we can find a way to minimize
>>> the amount of padding while keeping the timing and sizes statistically
>>> indistinguishable from that of Skype's, the traffic morphing technique
>>> greatly depends on the characteristics of the source protocol (Tor)
>>> and it's not easy to guess the timing patterns of user's behind
>>> Tor. So if we use traces from web-browsing behind Tor as the input to
>>> our software, and our client uses Tor for downloading multimedia
>>> content, in this case traffic morphing would not perform very well.
>> Hm, we encountered the same problem too, while working on the
>> "morpher" pluggable transport. Traffic morphing would not give us
>> satisfying results, and some times it would even result in more
>> overhead than randomly sampling from the probability distribution of
>> the target protocol.
>>
>> I think we identified the issue in trac ticket #5023 [0]. and also
>> wrote a report on it [1].
>> Another problem of traffic morphing which is not mentioned on that
>> report, is that traffic morphing works by using an oracle which gives
>> you an integer 'i' with (0 < 'i' <= MTU), and then you have to send a
>> packet of size 'i' to the wire. This usually means that you will
>> _never_ send fragmented IP packets, which looks quite sketchy.
>>
>> I don't think there are any non-messy solutions to the above problems,
>> except from realizing that mimicking the packet size probability
>> distribution of a protocol is probably not worth it at the moment (at
>> least against most current real-life adversaries). Especially so when
>> traffic morphing makes your traffic even more distinguishable in other
>> ways (like in the fact that it's not stateful).
> Interesting. So you also believe sampling from the target distribution
> is the best solution at the moment?

I'm not sure if there is a best solution here; it mostly depends on
your threat model.
       
If your adversary can somehow distinguish packet size probability
distributions in real-time, you will probably need to use direct
sampling or traffic morphing. I would personally stick with direct
sampling, for most cases here. By the way, at the same time, the
adversary should not be able to launch the attacks mentioned in my
previous post, which are much simpler than distinguishing packet size
probability distributions in real-time.

For less obscure but more realistic adversaries, I think sillier and
simpler padding or split-and-join schemes [0] might also be effective.

>>
>> Finally, 6 weeks ago I disabled dream.c in morpher.git [2], because I
>> suspect that the Matrix Market I/O library of NIST [3], that I was
>> using, is not the best piece of software engineering out there.
> So George how about the issue I brought up about pluggable transports
> and how we can stop Tor from making circuits while a transport is
> setting up a connection?
> https://trac.torproject.org/projects/tor/ticket/5483
>
> It's not envisioned in the current implementation of the pluggable
> transports, right?

You are not able to do this in the current pluggable transports
codebase, but we are developing schemes that will allow you to do
tricks like this in the future. I will update #5483.

[0]: mentioned here:
https://trac.torproject.org/projects/tor/raw-attachment/ticket/4679/pluggable-roadmap.pdf

_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev