Re: [tor-dev] Projects to combat/defeat data correlation

[Matthew Finkel <matthew.finkel@xxxxxxxxx>]

On Thu, Jan 16, 2014 at 06:12:47PM +0000, David Stainton wrote:
> In that case would it then look like zero in $(organizational unit of
> harvard) using tor and
> one in $(organizational unit of harvard) using scramble suit?
> 
> I like the idea of the tor pluggable transport combiner... wherein we
> could wrap a pseudo-random appearing obfuscation protocol (such as
> obfs3, scramblesuit etc) in a white listed obfuscation protocol such
> as http?, sshrproxy, hexchat etc.
> 
> I imagine the anonymity set would be much smaller for these combined
> transports... fewer people using them.
> 
> 
> On Thu, Jan 16, 2014 at 12:54 PM, Matthew Finkel
> <matthew.finkel@xxxxxxxxx> wrote:
> > On Wed, Jan 15, 2014 at 09:16:20PM -0600, Jim Rucker wrote:
> >> Are there any projects in Tor being worked in to combat data correlation?
> >> For instance, relays the send/recv constant data rates continuously -
> >> capping data rates and padding partial or non-packets with random data to
> >> maintain the data rates
> >
> > The very quick answer without providing much detail is that you may want
> > to look at scramblesuit [0][1]. It doesn't try to provide constant
> > throughput, but (as the website says) "we alter inter-arrival times and
> > the transported protocol's packet length distribution". This isn't a
> > perfect solution, and won't impress a GPA, but it's a start if you're
> > dealing with a localized passive observer.
> >
> > - Matt
> >
> > [0] http://www.cs.kau.se/philwint/scramblesuit/
> > [1] https://gitweb.torproject.org/user/phw/scramblesuit.git

yes? Technically this is true that if a user uses scramblesuit then they
will be very unique right now. However, the computational resources
required to associate a byte stream of pseudorandom bits with
scramblesuit is likely much larger than a university devotes to traffic
analysis on their network. This can likely also be generalized to larger
areas.

obfs3 is supposed to be fairly difficult to detect because entropy
estimation is seemingly more difficult than typically assumed,
and thus far from what has been seen in practice this seems to be true.

Also, if you are interested in combining PTs and want to
contribute check out ticket #10061 [2]. Successfully implementing a PT
that looks like a "white listed protocal" is also a fairly difficult
task, but if you can help then that would really be great.

[2] https://trac.torproject.org/projects/tor/ticket/10061
[3]
https://trac.torproject.org/projects/tor/wiki/doc/PluggableTransports#Combiningpluggabletransports

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