On Mon, 2004-02-02 at 21:17, Douglas F. Calvert wrote:
> - Right now, we never generate link padding or dummy messages. The code is
> there, but it never gets triggered. Specify when it gets triggered (and
> justify why this improves anonymity). (Spec difficulty: ????.
> Implementation difficulty: easy once you know how. Invasiveness: some.)
>
> When I was looking at this I thought that if the servers knew about the
> average/max/min/iqr of the data that it saw creating cover traffic would
> be easier. That is that you could flatten out the distribution manually.
Approaches of this form are often called "traffic shaping". Intuitively,
they seem promising, but there isn't (AFAIK) enough research to really
prove how much they help us, or how much is necessary, much less to
recommend one approach over another.
For long-range dummies, some amount of traffic shaping is probably
helpful (if the preliminary simulations for a revised version of [1] are
correct). For link padding, however, a geometric distribution of
dummies is enough to hamper many blending attacks (or so says the minion
paper[2][3]), and it's not clear that there are other attacks which
withstand geometric link padding but fall to traffic shaping.
[Please feel free to correct me where I'm wrong above; I haven't
actually re-read any of the papers recently.]
Another concern is efficiency: _any_ padding approach that we could do
will certainly result in an increased resource usage. Some approaches
(especially long-range dummies sent by users to 'round up' their message
volumes to a given threshold) need a _lot_ of extra resources. Before
we implement any of these approaches, we should probably have a sense of
how much, if at all, additional padding really helps, and (if it does)
how much is necessary.
[1] http://freehaven.net/doc/e2e-traffic/e2e-traffic.pdf
[2] http://mixminion.net/minion-design.pdf
[3] (Also see Len and George's paper about Red-Green-Black mixes for
another example of a more sophisticated way to use dummies to resist
blending attacks:
http://www.cl.cam.ac.uk/users/gd216/p125_danezis.pdf )
> Are there anonymity reasons why keeping tabs on data transmitted would
> be a bad thing? A best case situation would be to keep track of the
> statistics per server but something inside of me thinks that there might
> be problems with this.
Storing nearly any information hurts. Anything a mix stores, an
attacker who compromises the mix later can learn. In this case, the
vulnerability doesn't seem -especially- bad: an attacker who couldn't
observe past message volumes through a mix can, by compromising the mix,
learn them, and use them to help traffic analysis. (If we used link
padding, an attacker who compromised a mix could also learn how many of
the messages entering and exiting were link padding.)
So no, the exposure doesn't seem prohibitively bad, especially if we
only keep traffic history for a short window. The important thing is to
be sure that what we gain by such a strategy is actually better than
what we lose.
"More research is needed",
--
Nick
Attachment:
signature.asc
Description: This is a digitally signed message part