3 ms·

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 i

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

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.