Random chaff [was: more work for Grobbages]

grarpamp grarpamp at gmail.com
Thu Sep 24 08:21:51 UTC 2009


I was thinking solely of taps capable of observing user1, user2...
usern.

If user1 injects 1.21 MB of data on one side, and 1.21 MB of data
pops out the other side at injection time + network delay, the users
are made. Regardless of whether the observer can see inside the
network/crypto or operate in the network. And especially if the net
or users are quiet at that time.

But if there's chaff present, chaff that is only known to be chaff
by the network, or minimally by the recipient and generator, then
the game becomes harder. User1 and user2's pipes are always
independantly full of cap = ( chaff + wheat). Chaff is requested
from the network by the user's node to fill the cap during idle
times. The cap could be optional random dynamic, perhaps shrink
after some time of no wheat nearing the cap so as to not be needless
waste.

Users's nodes make [close?] peers just for traffic generation.
Tagged and controlled out of band. Involve the client's knowledge
that its socks or hidden service ports are generating n kbit/sec
of wheat.

Middle node link traffic could be similarly managed, albeit without
socks/hs knowledge, just bandwidth.

Any intelligent cell based clocking or committed rate management
within seem very hard when riding on the public internet. So it
would just be shoving bits into a hungry mouth until a gag message
comes back.

Maybe the problem with this idea is that the chaff generation system
might not be able to react fast enough when the real wheat travels
the pipes. So a 1.21 MB injection might still create some sort of
observable ripple at start and end times. The only way it might not
is if the pipes are oversubscribed _and_ packet lossy by design,
not just having the usual TCP congestion managed slowness. But that
would be terrible bad for most user facing applications and stacks.

Maybe it is the ripples that need hidden or randomized instead of
just filling pipes.

> If it turns out that correlation attacks are far more difficult
> than the research community thinks

It seems safe to presume that near global passive adversaries exist.
And certainly ones cabaple of covering various regions. And that
offline processing of the mesh of flow information from them is
probably within current capabilities. I'm actually amazed we're not
seeing canaries kicking off all over the place. Particularly ones
involving exits.

The advice to run a relay while using the client seems sound due
to whatever free chaff it brings. Who knows.

Thanks for the links to the anonbib and wiki. I want to read more
in the some free time.
***********************************************************************
To unsubscribe, send an e-mail to majordomo at torproject.org with
unsubscribe or-talk    in the body. http://archives.seul.org/or/talk/



More information about the tor-talk mailing list