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:iangat_private] Sent: Wednesday, June 02, 1999 6:18 PM To: cypherpunksat_private; coderpunksat_private 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"
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:48:09 PDT