Re: [tor-talk] Network diversity [was: Should I warn against Tor?]

[adrelanos <adrelanos@xxxxxxxxxx>]

Gregory Maxwell:
> On Fri, Jul 19, 2013 at 8:35 AM, Jens Lechtenboerger
> <tortalk@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
>> [For those who are confused about the context of this: I started the
>> original thread.  A write-up for my motivation is available at [0].]   I
>> Links to my code and a README.txt clarifying necessary prerequisites are
>> available at [0].   Best wishes Jens  [0]
>> https://blogs.fsfe.org/jens.lechtenboerger/2013/07/19/how-i-select-tor-guard-nodes-under-global-surveillance/
> 
> It's _very_ hard to reason about this subject and act safely.
> 
> It is common for ISPs to use segments in their network which are
> provided by third party providers, even providers who are almost
> entirely facilities based will have some holes or redundancy gaps.
> Because these are L1 (wave) and L2 (e.g. ethernet transport) they are
> utterly invisible from the L3 topology.
> 
> You can make some guesses which are probably harmless: a guard that is
> across the ocean is much more likely to take you across a compromised
> path than one closerâ    but going much further than that may well
> decrease your security.
> 
> These concerns should be reminding us of the importance of high
> latency mix networks... they're the only way to start getting any real
> confidence against a global passive observer, and the are mostly a
> missing item in our privacy tool toolbelt.

Seems like high latency mix networks failed already in practice. [1]

Can't we somehow get confidence even against a global active adversary
for low latency networks? Someone start a founding campaign?

[1] Not written by me. Source [2]

>  Roger Dingledine Fri, 27 Apr 2012 00:10:48 -0700
>
> On Thu, Apr 26, 2012 at 04:15:04AM +0100, StealthMonger wrote:
>> If the channel has low latency, no hacking can conceal the packet
>> timing and volume correlation at the endpoints.  It is high random
>> latency and thorough mixing that gain mixmaster its anonymity.
>> Dingledine and company would agree.
>
>
> Your "thorough mixing" phrase is critical here.
>
> Once upon a time, when we were working on both Mixminion and Tor, we were
> thinking of it as a tradeoff: Mixminion offers some protection against
> end-to-end correlation attacks [1], but the price is high and variable
> latency; whereas Tor offers basically no protection against somebody who
> can measure [2] flows at both sides of the circuit, but it's a lot more
> fun to use.
>
> (Another price of the mix design is that you only get to send a fixed-size
> relatively small message rather than have a bidirectional flow.)
>
> So oversimplifying a bit, we thought we had a choice between "high
> security, high latency" and "low security, low latency". But the trouble
> is that while Mixminion's design can provide more safety in theory, it
> needs the users before it can provide this safety in practice. Without
> enough users sending messages to mix with, high and variable latency by
> itself doesn't cut it.
>
> So oversimplifying a bit more, the choice may be better viewed as "low
> security, high latency" vs "low security, low latency". And that's a
> much easier choice to make. See [3] for more discussion.
>
> I haven't given up hope on end-to-end correlation resistance for
> low-latency flow-based designs like Tor (but papers like [4] don't make me
> optimistic for a quick fix). It's hard to see how we could end up with a
> large enough and diverse enough population of Mixminion users to let it
> fulfill its potential. Stay tuned to PETS [5] and related conferences,
> but be patient.
>
> --Roger

[2]
http://www.mail-archive.com/liberationtech@xxxxxxxxxxxxxxxxxx/msg00022.html

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