Gregory Maxwell: > On Fri, Jul 19, 2013 at 8:35 AM, Jens Lechtenboerger > <[email protected]> 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/[email protected]/msg00022.html _______________________________________________ tor-talk mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
