Re: [tor-dev] Website Fingerprinting Defense via Traffic Splitting

[Marc Juarez <Marc.JuarezMiro@xxxxxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/01/15 20:16, Daniel Forster wrote:
> 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..?
> 
> Thanks,
> 
> Daniel _______________________________________________ tor-dev
> mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx 
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)

iQEcBAEBAgAGBQJUrcD0AAoJEGfJ5xfgazlxR/QH+QGFs6SYCNTYLhzD7Q7mb0+i
sNkEj3/mRdsZd12TVP0y/rVGP45xKVYousNovVZDdzJDEmhHE5n98ceGVy0BZjKy
MnolxsQRYeFDimN5rytXCpLXgKdjInyZzDVwPgLDsuYLjaT24z3mXdMW2bSuIJd+
EV+B0bUI4XFCw5pQWgMywDXzXVA0RW6ZElPD0HUwIXetEqLOqwDu5wbXu+vglCAP
zzyKaR53TU5w4aYOnlr6+0RMLDro8A7UEx+QDRGpziuaxXItJXa45ALPvDGy/XYT
shyFTqikBMRL183QxmRXoqlrW7c8fo26YvFi9kOUoyrmhLjGBxmwgXA6CpKgwjU=
=UqFl
-----END PGP SIGNATURE-----
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev