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

[grarpamp <grarpamp@xxxxxxxxx>]

On 6/2/16, Allen <allenpmd@xxxxxxxxx> wrote:
> another alternative would be random packet sizes, ie, the packet size
> transmitted to the next hop would not be the same as the size received

What does this help / enable?

Nodes are known to GPA's, there is no way to hide them.
If GPA counting physical packets, over time period, bytes into a
relay must equal bytes out, otherwise they're being dropped
somewhere, which is inefficient... as opposed to temporarily
reducing fill to cover wheat demand.
There is up to %50 capacity loss with random sizes,
requiring up to 2x higher packet / interrupt rates to compensate
within the same pipe / cpu. And the code to do all the
carving, queuing and reassembly of every single packet, more
complex and costly than padding the last carrier packet
of some layer.

There is also to consider...
- physical / logical paths and pathing
- circuit, packet, label, or flow switching
- what layers the fill is in (above, at, or below wheat),
the layers managed at, and by who.

Big challenge is figuring how the network self
manages the fill system to dynamically make room
for wheat demand wherever it is needed in the network.
(That dynamic is also what makes the user apparent
application performance roughly the same as non fill
networks. Of course their NIC (or their configured
anonymous network rate limit within that), is always
saturated, but that's transparent to the application
layer.)

If that's all solved fill traffic might be a good defense to
Global *Passive* Adversary, and even a fair one to a
Global *Traffic Flow Perturbing Active* Adversary.
(What evidence is there that Global Adversaries
that are not partnered with Global Telecoms are able
to, as opposed to simply listening, arbitrarily drop /
inject / delay packets on the global backbones?)

Designing something new, including fill, crypto, and anonymity...
probably far harder than putting tor's basic design together was.
On the other hand, there's now 15 more years of research,
experience and components on hand to throw at it.
-- 
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