zks.freedom.flaws.txt

`Date: Sat, 29 May 1999 15:30:24 -0700  
From: Wei Dai <[email protected]>  
To: [email protected], [email protected]  
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 <[email protected]>  
To: [email protected]  
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:[email protected]]  
Sent: Wednesday, June 02, 1999 6:18 PM  
To: [email protected]; [email protected]  
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: [email protected]  
To: [email protected]  
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 <[email protected]> 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  
  
`