-----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