Date: Sat, 29 May 1999 15:30:24 -0700 From: Wei Dai To: cypherpunks@toad.com, coderpunks@toad.com Subject: a practical attack against ZKS Freedom Although the ZKS Freedom AIP protocol (as described in version 1.0 of the ZKS whitepaper) is conceptually similar to the PipeNet protocol, there are several attacks against ZKS which PipeNet is not susceptible to. The reason is that PipeNet uses end-to-end traffic padding, whereas ZKS only uses link padding. I came up with several attacks against link padding systems while developing PipeNet, which is why I ultimately choose end-to-end padding. However one can argue that end-to-end padding is too costly, and that these attacks are not practical because they require a global observer or the cooperation of one or more of the anonymous router (AIP) operators. ZKS has not publicly made this argument, but since they are probably aware of these earlier attacks they must have followed its reasoning. I hope the practicality of the new attack presented here will change their mind. In this attack, a user creates an anonymous route from himself through a pair of AIPs back to himself. He then increases the traffic through this route until total traffic between the pair of AIPs reach the bandwidth limit set by the ZKS Traffic Shaper. At this point the AIPs no longer send any padding packets to each other, and the real traffic throughput between them can be deduced by subtracting the traffic sent by the attacker from the bandwidth limit. This attack implies that link padding buys virtually no security. An attacker, without access to network sniffers or cooperation of any AIP operator, can strip off link padding and obtain real-time throughput data between all pairs of AIPs. If end-to-end padding is not used, this data would correlate with traffic throughput of individual users, and statistical analysis could then reveal their supposedly anonymous routes. --------------------------------------------------------------------------- Date: Thu, 3 Jun 1999 11:33:51 -0600 From: Tom Rawls To: BUGTRAQ@netspace.org Subject: FW: a practical attack against ZKS Freedom 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" --------------------------------------------------------------------------- Date: Fri, 4 Jun 1999 00:38:21 -0400 From: ender@beta.freedom.net To: cypherpunks@toad.com Subject: Freedom Beta I got my hands on a copy of the Freedom Beta from Zero-Knowledge. Here are my first impressions, 1) Ease of use The easy of use when compared to _ANY_ other remailer of Nymserver out there is incredible. It took me around 90 seconds to create my nym, with 3 reply blocks and start creating anonymous web, IRC routes. At the same time I think they need to get some help with usability, since I had to hunt for some of the features and some of the interface decisions are not that intuitive. (i.e. I couldn't find the e-mail address for my nym right away, I had to look in a preference setting. When I setup custom routing preferences I have to switch to regular user and then back to my nym to have it take effect - little things, but things that I think are important if they are going to get 10 million people using it). Overall, I'm REALLY impressed with the way they've packaged so much crypto and security in a really simple interface. At the same time, as a crypto geek, I'd like to be able to see more of things like my key fingerprints; more details about key lengths (Both for my nym and the servers that I choose to use). I hope they don't keep the interface so dumb that I can't ever get access to these things. 2) Speed I am actually pretty impressed with the speed. I'm using an ISDN dialup connection and with a three hop route (Going to of all places Quebec :) I was getting good speed. I noticed a little slow down with the way graphics were coming into my browser, but in general the throughput and performance was completely acceptable. (10kbps vs. 11.5 without Freedom on a sustained download) The whole idea that I can select my IP address and all of a sudden I had an IP number in Quebec, or Texas or Viriginia was very fucking cool. I can't wait until they have all their ISPs up and running and I can choose anywhere in the world to 'be'. There goes national borders :) 3) Security There is a big warning saying that I can't do any really _FUN_ things yet since the client hasn't passed a security review by Counterpane & Ian Goldberg yet. It's cool they are being open with that, but I still wish they were open source. Maybe if we call send them e-mail to asking for open source code - I understand from comments that Ian Goldberg has made that they are planning on releasing the source code once they can make sure that the anonymous network has critical mass and doesn't get split (ala BSD variants) - but I don't think this is a good enough reason. I personally won't use the software for anything other than general conversations until they do a wider audit or open the source code (Although if I had to pick only two people I trusted to review source code, it would be Counterpane and Ian Goldberg - but more is always good). At the same time I've sent my ISP 4 e-mails telling them to join the Freedom network and am going to be organizing a group of users at my ISP to make sure that we have a local Freedom node. Hopefully we can get some sort of commitment >from Zero-Knowledge about the number of Freedom nodes that need to be deployed before they open source - at least then we get to know if they are serious. I also ran a packet sniffer on my Windows box running Freedom and noticed that the connection to the first node is not being padded. (There is a constant stream of packets leaving my machine, but they are not running at a set speed. I understand from the release notes that this is not a secure version and there are still security improvements being made with regards to the routing so I'm waiting on this one.) SUMMARY I don't know how many people they gave this beta to, but my guess is if they fix some of the UI issues and get the security signed off by Bruce and Ian, we will have a WHOLE new way to play online and people like Jim Bell and Toto would be able to be back playing with us :) PS - I'm not Detweiler- but just wait 'till he sees this software. -Ender