Re: [tor-talk] On the Theory of Remailers

[Paul Syverson <syverson@xxxxxxxxxxxxxxxx>]

On Wed, Jan 09, 2013 at 10:20:06AM -0500, Tom Ritter wrote:
> On 9 January 2013 10:05, Alexandre Guillioud
> <guillioud.alexandre@xxxxxxxxx> wrote:
> > Hi all,
> >
> > I'm reading your conversation, and i'm not understanding very well what you
> > mean by high/low latency network. Isn't it just a ping duration delta ?
> > You speak about low and high latency like it's a feature.
> >
> > Is tor mixing only low latency with low latency in its circuits ? Opening
> > for a dispatching of services (ie. mail on high latency, web on low ) ?
> >
> > What's the point ?
> 
> Someone can probably explain it better by putting more time into it,
> but the gist of it is how long a mix node will 'hold onto' a message,
> before sending it on.  (Effectively 'mixing' it.)
> 
> >From the blog articles:
> 
> > A 'Low Latency' mix network means as soon as a node receives a packet, it sends it out. A 'High Latency' mix network means a node will hold onto a message for some amount of time before sending it out.
> >
> > Traffic Analysis is a huge part of mix network design. If an
> > attacker is watching the network (and we generally assume they
> > are) - how much information do they gain by watching packet paths,
> > sizes, and times, and how easy is it? If you see a network flow
> > from Alice to Bob, and Bob to Charlie - those flows will probably
> > be matchable. With regard to defending against Traffic Analysis,
> > High Latency is preferable - being able to hold onto a packet for
> > any length of time before sending it on gives you lot more
> > options.
> >
> > Tor is a 'Low Latency' mix network - it has no choice because it's
> > infeasible to browse the Internet with minute-long (or longer)
> > delays during page loads. However, email can have delays - if an
> > email doesn't arrive for 30 minutes or an hour, it's generally not
> > a problem. So Remailers can afford to be a High Latency mix
> > network. They will accumulate a number of messages in a pool, and
> > then when the pool is a certain size, will send the messages
> > out. There are multiple algorithms for pooling, and we'll go into
> > more detail about them and pool attacks later.
> 
> As a mix node, if I accumulate 8 same-size messages, and then send
> them all out at once to 8 recipients, you can't use traffic analysis
> to see who I sent which message out to - because they're
> indistinguishable.  That's high latency.  But if I had sent out each
> message as soon as I got it, you could see which message went to each
> recipient - that's low latency.
> 

Right. Tor isn't mixing at all. Onion routing gets its security from
the observation that even adversaries that can be anywhere typically
can't be everywhere. This is true whether one is trying to protect
properties of the communication between source and remote destination
(typically called anonymity) or protect properties of the
communication between the source and the onion routing network
(typically called circumvention or obfuscation).

Mix network security analysis typically assumes adversaries are on all
links between mixes and at some compromised mixes as well. Tor is
broken against such a model. But, and this is a huge but, while the
above is all correct, it perpetuates the mistaken view that the only
thing going on is a security/practicality tradeoff that mix networks
resolve more in favor of security and onion routing networks resolve
more in favor of practicality. In several important respects Tor is
more secure than any practically deployed, but also practically
deployable mix network. I discuss this more in "Why I'm not an
Entropist" and "Sleeping dogs lie on a bed of onions but wake when
mixed", both available on my webpage (http://www.syverson.org).

That said, I continue to think that combining different latency
traffic as we discussed in the alpha mixing paper mentioned earlier in
this thread can provide real benefit for some applications and
plausible adversaries (although I think what we called 'tau-mixing' in
that paper is the more likely fruitful departure point). But departure
point for someone else: there are years worth of higher-priority-to-me
Tor-related research problems to solve, so it is back-burnered
indefinitely or until somebody entices me that working on this
is worth pulling away from other things.

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