Michael Rogers michael@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