New subject: [tor-talk] Tor (and other nets) probably screwed by Traffic Analysis by now

2 Jun 2016

      On 6/2/16, Allen  wrote:
...
Another alternative would be to re-architect the services of interest to
use a message or packet store-and-forward protocol with a random delay to
thwart traffic analysis.
Perhaps different terms for same derivative thing?
...
From other searchable and recent threads...
Fill traffic needs store and forward with random delay, for low latency
requirements it could be called reclocking with jitter, rearchitecting
for higher latency adds additional bounds on time to the interval
and jitter clocks. Packet / message oriented / UDP seems useful
to remove constraints of TCP-in-TCP allowing for management
of fill traffic, multipath traffic spreading, pluggables, and so on.
Ineffective is say rearchitecting web "services" to deliver a tarball
of a website for offline reading, if said delivery is over a traditional
non fill network, it will be TA'd.

Fill / chaff seem needed, otherwise in an all wheat network,
input traffic on one side seems to match output traffic on the
other side at some point, regardless of storage / delay.
Fixed packet sizes seem to help.
Fill ratios up to 100% utilization can mask the wheat.
Minimum fill is amount needed for plausible deniability
that single input can't be mapped to a single output.
ie: 10MiB in, must have at least two outputs that
received 10MiB.

Is there any group / list that is actively researching
or developing such networks? Or that wants to?

Re: [tor-talk] Tor (and other nets) probably screwed by Traffic Analysis by now

grarpamp

Steve Kinney

StealthMonger

grarpamp

tags

participants (3)