Daniel Forster: > Hello Guys, > > it would be great if I could get a few opinions regarding my > upcoming master thesis topic. > > My supervisor is Andriy Panchenko (you may know some of his work > from Mike Perry's critique on website fingerprinting attacks). > As a defense, we'd like to experiment with traffic splitting (like > conflux- split traffic over multiple entry guards, but already > merging at the middle relay) and padding. > > I know that the no. of entry guards got decreased from three to one. > May it be worth the research or is the approach heading in a not so > great direction w.r.t. the Tor Project's "only one entry node" > decision? Or, actually, what do you think in general..? 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. 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. 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/ideas/xxx-multihop-padding-primitives.txt?h=multihop-padding-primitives 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
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev