Is it possible to specify voluntary delays in my Tor client?
I.e., if I want the extra resistance to traffic analysis that higher latency connections provide, is there a way to specify that in my Tor config? -V
On Tue, Jan 19, 2016 at 3:03 AM, Virgil Griffith <i@virgil.gr> wrote:
I.e., if I want the extra resistance to traffic analysis that higher latency connections provide, is there a way to specify that in my Tor config?
Higher latency, in and of itself, does not provide any resistance to traffic analysis. https://en.wikipedia.org/wiki/Latency_(engineering) Higher global jitter might help, but circuit orientation at guards and exits through to the clients seems to nullify that. https://en.wikipedia.org/wiki/Jitter For which an idea may to become packet switching, which is really no longer Tor. https://en.wikipedia.org/wiki/Packet_switching Link padding seems the next real step but I've not put enough reading to it, only have idea to read about. Nor do I yet review about Tor padding proposal as sufficient or not, sorry. As it is not the Tor original model design maybe some other network will take this analysis / padding issue up before then. I've no idea.
I understand that the original Tor model is to set low-latency and low-jitter as a constraint as to permit things like interactive web-browsing etc. And yes, I presume Tor will always have this as a constraint. I am asking if: (1) There currently exists some way I can specify in my torrc to sacrifice some of these in exchange for a little greater anonymity protection (say I want to slowly leak a file, etc.) (2) If not, how difficult would be it to shoe-horn this into the current tor model? In short, if it's not too difficult, I can look into finding funding it. -V On Wed, Jan 20, 2016 at 1:37 PM, grarpamp <grarpamp@gmail.com> wrote:
On Tue, Jan 19, 2016 at 3:03 AM, Virgil Griffith <i@virgil.gr> wrote:
I.e., if I want the extra resistance to traffic analysis that higher latency connections provide, is there a way to specify that in my Tor config?
Higher latency, in and of itself, does not provide any resistance to traffic analysis.
https://en.wikipedia.org/wiki/Latency_(engineering)
Higher global jitter might help, but circuit orientation at guards and exits through to the clients seems to nullify that.
https://en.wikipedia.org/wiki/Jitter
For which an idea may to become packet switching, which is really no longer Tor.
https://en.wikipedia.org/wiki/Packet_switching
Link padding seems the next real step but I've not put enough reading to it, only have idea to read about. Nor do I yet review about Tor padding proposal as sufficient or not, sorry.
As it is not the Tor original model design maybe some other network will take this analysis / padding issue up before then. I've no idea. _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
The Differences Between Onion Routing and Mix Networks https://ritter.vg/blog-mix_and_onion_networks.html On Wed, Jan 20, 2016 at 5:42 AM, Virgil Griffith <i@virgil.gr> wrote:
I understand that the original Tor model is to set low-latency and low-jitter as a constraint as to permit things like interactive web-browsing etc. And yes, I presume Tor will always have this as a constraint.
I am asking if: (1) There currently exists some way I can specify in my torrc to sacrifice some of these in exchange for a little greater anonymity protection (say I want to slowly leak a file, etc.)
(2) If not, how difficult would be it to shoe-horn this into the current tor model? In short, if it's not too difficult, I can look into finding funding it.
-V
On Wed, Jan 20, 2016 at 1:37 PM, grarpamp <grarpamp@gmail.com> wrote:
On Tue, Jan 19, 2016 at 3:03 AM, Virgil Griffith <i@virgil.gr> wrote:
I.e., if I want the extra resistance to traffic analysis that higher latency connections provide, is there a way to specify that in my Tor config?
Higher latency, in and of itself, does not provide any resistance to traffic analysis.
https://en.wikipedia.org/wiki/Latency_(engineering)
Higher global jitter might help, but circuit orientation at guards and exits through to the clients seems to nullify that.
https://en.wikipedia.org/wiki/Jitter
For which an idea may to become packet switching, which is really no longer Tor.
https://en.wikipedia.org/wiki/Packet_switching
Link padding seems the next real step but I've not put enough reading to it, only have idea to read about. Nor do I yet review about Tor padding proposal as sufficient or not, sorry.
As it is not the Tor original model design maybe some other network will take this analysis / padding issue up before then. I've no idea. _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On Wed, 20 Jan 2016 08:15:48 +0000 David Stainton <dstainton415@gmail.com> wrote:
The Differences Between Onion Routing and Mix Networks https://ritter.vg/blog-mix_and_onion_networks.html
Not implemented yet in tor (see prop 254), but this is the current state of the art in link padding as a traffic analysis defense. http://arxiv.org/abs/1512.00524 This is follow up research from M. Juarez's GSOC project which prototyped the framework used when writing the paper and evaluating the various algorithms. Regards, -- Yawning Angel
participants (5)
-
David Stainton -
grarpamp -
Spencer -
Virgil Griffith -
Yawning Angel