On Fri, May 29, 2015 at 7:02 PM, Ryan Carboni <ryacko@gmail.com> wrote:

...

That's only if you choose to attempt a padding-across-the-net management scope, which is also going to be hard and slow to manage and respond to bandwidth and other net dynamics. (Though this was about GPA, it's probably also vulnerable to endpoint interruption attacks that monitor your stream, unless someone is there making up the padding slack at the far end.) A wide scope seems hard in a low latency demand based net. I'd suggest examining some form of next-hop, next-peer, or link local padding scope negotiated with such peers. If you or your peers get hit with demand, your negotiation distance is shorter.

That would still leak additional information, to a lesser extent.

Passive adversaries see only encrypted traffic, not internal wheat/chaff ratios. (If considering active adversaries, which this is not meant to defend against, to be involved in ratios they would have to run enough nodes to be over half the full path, no worse than basic entry to exit correlation today.)

Regardless, I don't think the TOR network has the bandwidth or

Internet access is generally provisioned and billed as... choose the max bandwidth you want, pay for it whether you use it or not. Therefore if you have idle capacity within your max at some moment, you have the bandwidth to dynamically fill it with padding at no additional cost. It's not a question of buying more to use as fill, it's about intelligently filling what you've already comfortably paid for. The problem of observing when endpoints are sitting idle, or rx/tx, and how much, often, etc... applies to any network today, not just tor.

computational capacity for padding.

It doesn't take a supercomputer to calculate this regarding your logical link to your next hop node... 100Mbps cap - 63Mbps used = 37Mbps fill

It'd require more bookkeeping.

That's head in sand talk, of course nothing is free. Mostly bookkeeping autonomously on and by the local node. Maybe some circuit signaling / publishing to DHT. Seems to get more complex if you try to scope it across the net instead of just to your next hops. There were threads on the subject of fill traffic a few months back that might be worth reading... "high latency hidden services" "traffic analysis" "traffic analysis -> let's write an RFC?"