Re: [tor-dev] high latency hidden services

[Michael Rogers <michael@xxxxxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

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.

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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBCAAGBQJUbgMZAAoJEBEET9GfxSfMWegIAL/IQj7uOVSqd3kG+SSj/bCx
RxyAkYmvS9josfDdtyOqDEJ3wMUcjMK313SPOA6vFWkkDYPqkbrXPwWCFMLJK/2m
qVJ/ZItrno0RiOpTBEij2s7/VYW5ECzYjZUe3+O8lveYLz6k7IXXRiVkJt3y1oFn
ze2Hl4XqTi7/rwaE9Q6JPfMBk4zcH4POtUaEYdpDME60QQQ8HRn0s2W9QlWihvrT
ALhBqWXqZAZwEw1iKokT4XG/6HhGSs0WKgL53+wjfHTb6UdRTCas+nc/YuBuOVun
45OWmI8DuUG6YgxT5NEHKUL+OGts4ikoJ2TZwZ7Xjhd4zrgU+bZXTXDOQgUmJTY=
=rcBt
-----END PGP SIGNATURE-----
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev