On Jan 7, 2015, at 9:13 PM, Mike Perry <mikeperry@torproject.org> wrote:

I think regardless of our current entry guard choice (which is governed by the consensus and subject to relatively easy change, btw), having a datapoint on how traffic splitting affects Website Traffic Fingerprinting accuracy would be a very useful research contribution.

I am in general very concerned that basically one research paper caused us to make a decision to switch to a single, long-lived guard, and that a core assumption underlying this research paper is that traffic correlation is always perfect. Research that can at least shine some light on the actual tradeoff we made here seems generally useful and important.

Okay, this is enough motivation. My concerns were small though, but I liked to ask beforehand..

One thing I would ask is that for this particular piece of research, you also investigate the accuracy of an adversary that gets to see both links, but externally (ie a censoring/surveilling national firewall). I suspect that for such adversaries, there won't be much benefit from just splitting by itself, but we may end up surprised by how splitting and padding interact together with conflux-style load balancing. There may be emergent effects there that further complicate the attack, even for a local observer such as this.

Yes, of course! We feel like this too, and we will evaluate the effect of the system when the adversary is able to see and merge the mutliple streams.

Hopefully you are also aware of our attempts to prototype padding defenses to the first hop using pluggable transports. See in particular: https://gitweb.torproject.org/user/mikeperry/torspec.git/tree/proposals/idea... https://bitbucket.org/mjuarezm/obfsproxy-wfpadtools/ and https://lists.torproject.org/pipermail/tor-dev/2014-December/007977.html

Perhaps you could save some implementation effort by laying these pluggable transports on top of a native tor splitting/conflux mechanism?

You may also be able to collaborate with Marc Juarez in other aspects of this research, too. There's a lot to study here, I think.

-- Mike Perry

Thanks for the pointers, I wasn't aware of all of them. And yes, the plan is to implement the splitting part and then use pluggable transports for the padding part. Daniel

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

Hi Marc, your plans for the wfpadtools framework sound really interesting. An evaluation framework of website fingerprinting defenses would be really useful! I would be happy to use it to evaluate the splitting/padding approach. Like you and Mike said, I have to implement the splitting in Tor first but I will definitely come back to you when this first step is done. Thanks, Daniel

Hi Daniel,

I find it a very interesting idea to explore.

I feel that a smart use of padding in combination with splitting will be necessary in order to see improvements. The most immediate effect of splitting is to conceal packet lengths, but Tor fixed-length cells already make length not an interesting feature to exploit in WF attacks. Even if the cells are routed through different entry guards, ISP-like adversaries sitting between the user and the entry have the advantage of knowing the origin of the fragments. However, DLP strategies combined with Conflux-like splitting can be interesting. Also, routing through different entries seems to raise the bar for internal adversaries only controlling entry guards.

As Mike already mentioned, the framework we developed within the GSoC project allows to implement a wide range of padding strategies in the first hop, including chopping packets at arbitrary lengths (e.g., following a length distribution). But, as Mike pointed out, the framework is implemented as a PT and a Conflux-like strategy that reassembles fragments at the middle-node requires to be implemented in Tor itself.

I'm still working on the framework, currently refactoring and implementing new defenses. My goal now is to extend it to become an evaluation framework of WF defenses. So, I'm definitely interested in this topic. My research is closely related to WF, so I'm up for a collaboration on this as well as in other related problems.

Best, -- marc

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

On Thu, Jan 08, 2015 at 10:52:17AM -0800, Arlo Breault wrote:

It seems like the dark (tangent-like) line running through the middle of the uptimes (not the conspicuous vertical stripe you describe) is just a consequence of the sorting.

Yes, how it works is we first sort by center of mass, then by total uptime. The center of mass moves from left to right as you look from top to bottom. It turns out that there are many descriptors that are only up for one or two hours out of an entire month. Those are what make the dark stripe. The big surprise is how many descriptors there are. In November, there were 13,242 unique descriptors seen, more than double the steady-state total number of relays. Many relays appear for a short time and then disappear forever. The black band at the center consists of the actual stable relays. Above and below that is a lot of churn.

Are the vertical white lines periods where a consensus wasn’t reached?

Yes, there are some missing hours in the input files. David Fifield