[tor-dev] high latency hidden services

[George Kadianakis]

Michael Rogers <michael at briarproject.org> writes:

> On 09/11/14 18:33, Mansour Moufid wrote:
>> Has there been research on integrating high-latency message
>> delivery protocols with the hidden service model of location
>> hiding?  The SecureDrop or Pynchon Gate protocols sound like good
>> starting points. I would love to participate, and encourage
>> everyone to start in this direction (in your copious free time ;).
>
> This issue has just come up on the guardian-dev list, so we're moving
> the conversation over here. Context quoted below.
>

Yes, integrating low-latency with high-latency anonymity is a very
interesting probleml. Unfortunately, I haven't had any time to think
about it.

For people who want to think about it there is the "Blending different
latency traffic with alpha-mixing" paper. Roger mentioned that one of
the big challenges of making the paper usable with Tor, is switching
from the message-based approach to stream-based.

Other potential papers are "Stop-and-Go-MIX" by Kesdogan et al. and
"Garbled Routing (GR): A generic framework towards unification of
anonymous communication systems" by Madani et al. But I haven't looked
into them at all...

Another interesting question IMO, is whether we can build wrappers so
that we can do WWW/XMPP/etc. over higher-latency anonymity systems.

If anyone wants to do some research and present some preliminary
results or ideas here, it would be awesome. We can also turn it into a
blog post for blog.torproject.org if it's good!

> On Thu, Nov 20, 2014, at 09:46 AM, Michael Rogers wrote:
>> On 20/11/14 14:21, Nathan of Guardian wrote:
>>>> If we simply use Tor as a low-latency transport for
>>>> asynchronous messaging then we're limited to Tor's threat
>>>> model, i.e. we can't prevent traffic confirmation attacks. If
>>>> we revive one of the remailers or build a new system then we're
>>>> limited to a small number of users, i.e. a small anonymity set.
>>>> So ideally we'd find some way of adding high-latency mix-like
>>>> features to Tor.
>>> 
>>> How much difference in latency are we talking about? Can we just
>>>  introduce some sort of randomness or delay into our existing 
>>> stacks/protocols?
>> 
>> If we add delays at the application layer then those delays will
>> be the same all along the Tor circuit. So from the point of view of
>> an adversary doing a traffic confirmation attack against Tor, the
>> delays are irrelevant: the adversary sees the same pattern of
>> delays at both ends of the circuit, so the ends are still
>> correlated with each other.
>> 
>> To decorrelate the traffic entering Tor from the traffic leaving
>> Tor we need to delay the traffic at each hop. Ideally we'd go
>> further than that and decouple high-latency traffic from circuits,
>> so that traffic could enter Tor on one circuit and leave on another
>> circuit, long after the first circuit was closed. But that's a much
>> harder problem than adding a delay at each hop, I think.
>> 
>>>> Done right, this could provide a large anonymity set for the 
>>>> high-latency users and improve the traffic analysis resistance
>>>> of Tor for the low-latency users at the same time, by providing
>>>> a pool of latency-insensitive traffic to smooth out the bursty 
>>>> low-latency traffic between relays.
>>> 
>>> I think this really makes the case, why a native Tor-based 
>>> messaging channel/layer/link/substrate should be implemented.
>> 
>> Great! Maybe we should move this discussion to the thread on
>> tor-dev that Mansour Moufid started recently?
>
> Cheers,
> Michael