-----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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev