[tor-dev] SkypeMorph

[George Kadianakis]

Hooman <hmohajer at cs.uwaterloo.ca> writes:

>>>> D) The morphing output is basically identical to the naive shaping. Are
>>>> you sure you did it right?
>>> So as mentioned in the report, the original traffic morphing does
>>> not consider timing at all (which makes it less effective against
>>> DPIs) and it aims at minimizing the overhead, ie the number of
>>> padding bytes sent on the wire.
>> Right. Minimizing padding bytes on the wire is a big reason to like it.
>>
>>> When we introduced the inter-packet
>>> timing feature, it was no longer possible to go with the same
>>> construction, since packets may not be send right away. As a result
>>> we tried a different approach for traffic morphing: we buffered
>>> packets received from Tor, then when it is time to send the next
>>> packet, we simply estimate the original packet size by a sample form
>>> the Tor's packet size distribution. I know there are other ways this
>>> can be done, but in our experiment we didn't observe any tangible
>>> difference in the outcome.
>> Hrm. So that means your traffic morphing algorithm doesn't try to reduce
>> padding bytes? That makes your graph 5 make more sense. But is it really
>> accurate to call it morphing still? It would be great to explore that
>> tradeoff more.
> 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).

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.

[0]: https://trac.torproject.org/projects/tor/ticket/5023
[1]: https://trac.torproject.org/projects/tor/raw-attachment/ticket/5023/morpher.2.pdf
[2]: https://gitorious.org/morpher/morpher/commit/73d30a0b5aad54d2d52b542d45253c0eedac7456
[3]: http://math.nist.gov/MatrixMarket/mmio/c/mmio.c