Hooman hmohajer@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]: https://gitorious.org/morpher/morpher/commit/73d30a0b5aad54d2d52b542d45253c0... [3]: http://math.nist.gov/MatrixMarket/mmio/c/mmio.c