5 ms·

one: that limitation is obvious, technologies such as the following can assist https://en.wikipedia.org/wiki/Multicast https://en.wikipedia.org/wiki/Multicast

one: that limitation is obvious, technologies such as the following can assist https://en.wikipedia.org/wiki/Multicast https://en.wikipedia.org/wiki/Multicast two: i don't understand how encrypted traffic that maintains a noise level and hides encrypted data in the noise can be subject to traffic analysis. third: popularity, that is a solved problem for the majority of limited bandwidth systmes, you get lag. fourth users inclination: both endpoints being comprimised to that extent is beyond the scope of most counter surveillance technology that i have ever heard of. of the criticisms only the one i labelled two seems really interesting to me, could you please elaborate? i was able to run voice comms and play computer games simultaneously on isdn and modem lines and therefore the voice bandwidth concerns i don't think are realistic

schoen 11y ago
It's possible that it might turn out to be voice-capable, I'd like to see how the Guardian Project's work with voice over Tor has gone. But there is a notion that more latency is better for anonymity, and clearly worse for voice, and we don't even necessarily know where the sweet spot is for anonymity. And the anonymity that you get from something like Tor is already of questionable value against either a global adversary or one who's already monitoring you. To make the anonymity stronger there, we have to make the latency worse. The traffic analysis comes in where you notice correlations between increased or decreased activity on one link and a corresponding change in activity on another link. Just having noise isn't necessarily enough to spoil those correlations; after all, so much of modern statistics is about detecting very weak signals given many noisy observations. There is also research about active attackers shaping traffic flows (like delaying or blocking packets injecting additional packets). Then the notion is that the changed shape of a flow will be visible elsewhere on the network, and that's the destination. Unfortunately, this seems to work really well!
- throwawayaway 11y ago
  I don't think you have followed me at all. The intention is to send a noisy level of encrypted 'constant' bandwidth. The activity has the same random level of increased and decreased activity the whole time, active or inactive. How are you not getting this? endpoint0-n ---> 'server' ---> endpoint0-n where ---> is a random level of encrypted noisy signal. the endpoint does not open a connection to the other endpoint, it opens it to the 'server'. no amount of traffic analysis or packet injection is going to mess with that. the absolute best traffic analysis can do is provide a 1/n probability based on active connections to the 'server' that endpointA was talking to endpointB. > we have to make the latency worse. > there's a notion that latency is good for anonymity we have to do something because of a notion? i give up.
  - schoen 11y ago
    So if you can guarantee that the probability distributions of the number of bytes sent between the endpoints and server in a time window are unaffected by whether or not communication was happening in that time window, your approach is totally valid. Pond does have that property, if you use the defaults. I don't think a lot of other systems do. The tradeoffs are pretty steep in terms of delaying interactions until the next time window, sending and receiving cover traffic in every time window, and accepting hard limits on your data rate that are bounded by the cover traffic. What I think you can't do safely, for example, is say "I have a cover traffic pattern that is a Gaussian distribution of amount of data transmitted and received, and now I have to send a bunch of data, so I'll just pick the high of the distribution and send a whole bunch of data at once". One reason this is unsafe is that you'll simultaneously skew the recipient's distribution, creating a statistical signal that you and the recipient were communicating.
    - throwawayaway 11y ago
      the amount of traffic to the 'server' is completely random. the traffic from the 'server' is completely random and unrelated to the traffic into it. within this level of encrypted traffic noise, data is carried, smaller than the carrying capacity of that traffic.

schoen 11y ago

It's possible that it might turn out to be voice-capable, I'd like to see how the Guardian Project's work with voice over Tor has gone. But there is a notion that more latency is better for anonymity, and clearly worse for voice, and we don't even necessarily know where the sweet spot is for anonymity. And the anonymity that you get from something like Tor is already of questionable value against either a global adversary or one who's already monitoring you. To make the anonymity stronger there, we have to make the latency worse. The traffic analysis comes in where you notice correlations between increased or decreased activity on one link and a corresponding change in activity on another link. Just having noise isn't necessarily enough to spoil those correlations; after all, so much of modern statistics is about detecting very weak signals given many noisy observations. There is also research about active attackers shaping traffic flows (like delaying or blocking packets injecting additional packets). Then the notion is that the changed shape of a flow will be visible elsewhere on the network, and that's the destination. Unfortunately, this seems to work really well!

throwawayaway 11y ago
I don't think you have followed me at all. The intention is to send a noisy level of encrypted 'constant' bandwidth. The activity has the same random level of increased and decreased activity the whole time, active or inactive. How are you not getting this? endpoint0-n ---> 'server' ---> endpoint0-n where ---> is a random level of encrypted noisy signal. the endpoint does not open a connection to the other endpoint, it opens it to the 'server'. no amount of traffic analysis or packet injection is going to mess with that. the absolute best traffic analysis can do is provide a 1/n probability based on active connections to the 'server' that endpointA was talking to endpointB. > we have to make the latency worse. > there's a notion that latency is good for anonymity we have to do something because of a notion? i give up.
- schoen 11y ago
  So if you can guarantee that the probability distributions of the number of bytes sent between the endpoints and server in a time window are unaffected by whether or not communication was happening in that time window, your approach is totally valid. Pond does have that property, if you use the defaults. I don't think a lot of other systems do. The tradeoffs are pretty steep in terms of delaying interactions until the next time window, sending and receiving cover traffic in every time window, and accepting hard limits on your data rate that are bounded by the cover traffic. What I think you can't do safely, for example, is say "I have a cover traffic pattern that is a Gaussian distribution of amount of data transmitted and received, and now I have to send a bunch of data, so I'll just pick the high of the distribution and send a whole bunch of data at once". One reason this is unsafe is that you'll simultaneously skew the recipient's distribution, creating a statistical signal that you and the recipient were communicating.
  - throwawayaway 11y ago
    the amount of traffic to the 'server' is completely random. the traffic from the 'server' is completely random and unrelated to the traffic into it. within this level of encrypted traffic noise, data is carried, smaller than the carrying capacity of that traffic.