Michael Rogers <mich...@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 _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev