Re: [tor-talk] [Cryptography] Dark Web should really be called the Twilight Web

[grarpamp <grarpamp@xxxxxxxxx>]

On Fri, May 29, 2015 at 7:02 PM, Ryan Carboni <ryacko@xxxxxxxxx> 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?"
-- 
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk