[10709] in bugtraq
FW: a practical attack against ZKS Freedom
daemon@ATHENA.MIT.EDU (Tom Rawls)
Thu Jun 3 14:06:33 1999
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Message-Id: <2529CB729AE7D211A5C80008C7F4536E0DE2F5@EXCHANGE1>
Date: Thu, 3 Jun 1999 11:33:51 -0600
Reply-To: Tom_Rawls@SENTO.COM
From: Tom Rawls <Tom_Rawls@SENTO.COM>
To: BUGTRAQ@NETSPACE.ORG
Jay, I don't know if you've seen this yet, but here's Ian Goldberg's answer
to that.
-----Original Message-----
From: Ian Goldberg [mailto:iang@cs.berkeley.edu]
Sent: Wednesday, June 02, 1999 6:18 PM
To: cypherpunks@cyberpass.net; coderpunks@toad.com
Subject: Re: a practical attack against ZKS Freedom
In a recent post, Wei Dai proposes an attack against the whitepaper
design of the Freedom Network. The points he makes are, to first
approximation, well-taken, with some additional caveats.
The link padding removal method described cannot be used to remove the
padding from links between the client and the rest of the network, since
the client does not route external traffic. As such, packets from a
particular client cannot be observed entering or exiting the network.
Regardless, of course, if all other (server to server) link information
were available, a statistical attack to find the identity of the client
would be relatively straightforward.
A second point (somewhat tangential) is that the link padding between
servers does not in fact bring the total traffic between servers
(necessarily) to a constant value. All that is required to prevent
_passive_ eavedroppers from gaining information is that the total amount
of traffic be padded to a _data-independent_ function. A constant is
the simplest such function, but there are others. A function involving
randomness is better in some ways, though without careful choices for
where to use randomness (note that this is _not_ talking about the
quality of the random numbers themselves, but rather the logical part of
the protocol in which randomness is inserted), the randomness can often
be removed statistically. Discovering the patterns that are best-suited
for use in link padding is part of the research behind this product.
Hopefully, a correct choice of function would make it difficult for Wei
Dai's attacker to use up exactly all of the padding, and thus determine
the actual (non-padding) throughput of the link.
Now, what we plan to do about it:
(1) End-to-end padding is a specific case of "red link" padding. [The
Freedom Network consists of two kinds of links, referred to as "red
links" and "blue links". The blue links are the server-to-server direct
connections. "Link-padding" is padding of the blue links. The "red
links" are the nested connections between the client and each of the
servers in the chain.] As the Freedom Network grows, we plan to
incorporate a high-bandwidth "core" network, as well as lower-bandwidth
nodes hanging off of the core to a number of levels (think nested
rings). The red links from the client into the core (which should take
about three hops) will likely be padded, whereas the links out of the
core (through the lower-bandwidth links) may not be. Using this method,
Wei Dai's attacker could only (statistically) trace a route as far back
as the core, where all traffic goes through, anyway. (Do not mistake
the core for a central point of failure; the core itself will be made up
of a large number of well-connected nodes, around the Internet.)
(2) The possibility of introducing some manner of "reservations". This
is further off in the design, but it prevents the attacker from
observing the actual throughput between nodes, without the cost of
blindly carrying padding traffic around the network. The attacker can
still gain some information if he compromises a number of nodes on the
route, but that's pretty fundamental. The tricky bit of reservations is
preventing DoS attacks wherein an attacker (under many nyms) reserves
all the available bandwidth. Again, a research issue.
In summary, the attack presented is an interesting one. We claim, however,
that strict "end-to-end" padding is not fundamental to the solution;
rather, other techniques ("red link" padding / reservations with link
padding) can also be used (at a somewhat lower cost to the network)
to prevent the attack.
- Ian "Chief Scientist and Head Cypherpunk, Zero Knowledge Systems"
