Re: [tor-dev] SkypeMorph

[Hooman <hmohajer@xxxxxxxxxxxxxxx>]

On 12-03-28 06:57 PM, George Kadianakis wrote:
> Hooman <hmohajer@xxxxxxxxxxxxxxx> 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).
Interesting. So you also believe sampling from the target distribution
is the best solution at the moment?
>
> 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?
> [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
>
> _______________________________________________
> 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