December 2003 - cypherpunks-legacy

cpla mailing list revived
by jpp＠markv.com 17 Dec '03

17 Dec '03

The quietness of the cpla list was brought to my attention recently. I have improved the list software, changed the list address into a real internet style mailing list. You should now be able to be join and depart the cpla mailing list automatically. Who knows, this might even prompt a physical get-together. I will be adding the members of the old list to the new list, so expect to get another copy of the welcome message if you were on the cpla list a while ago. Here is a copy of the welcome message, FYI. Welcome to the Cypherpunks LA <cpla(a)markv.com> mailing list. Like every moderator of every new list, I hope this will be mostly signal and very little noise. I don't envision this as a general discussion list -- that's what the main list is for. This list is for: Coordinating physical meetings of Cypherpunks in the Los Angeles area: Location, time, equipment, arranging rides, etc. Suggesting topics to cover at the meetings. Coordinating other local group activities. Announcements of relevant talks, seminars and other such goodies in the Los Angeles area and environs. *Concise* pointers to other local groups, mailing lists, and sources of information that might be of interest to local Cypherpunks. Whatever everyone seems to use it for. This list is NOT for: Reposting the "important" messages from the main list or any other mailing list or newsgroup. (If someone wants to run a "distilled" Cypherpunks list, fine. This isn't it!) Preaching to the converted. No ranting! (If you want to rant, do it on the main list. Everyone else seems to...) Rehashing the same topics that are going on the main list. This list is now managed by a simple minded program. Send a message with a blank body and the subject 'subscribe' to be added to the list. The subject 'unsubscribe' will remove you from the list. Any suggestions for how to improve this intro are welcome. Any suggestions for a *local* FAQ are also welcome. Direct your sugestions to me at jpp(a)markv.com. PGP/ViaCrypt mail gladly accepted. This information is also available at ftp://ftp.markv.com/pub/jpp/cp-la-hi.txt j' <jpp(a)markv.com>

1 0

traffic analyzing Chaum's digital mix
by Wei Dai 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- I have been thinking about the problem of traffic analysis of a remailer. More specifically, the problem is how can Eve trace Bob, who is communicating with Alice through an ideal Chaumian digital mix? (As most of you know, current remailers are missing many of the features of the digital mix Chaum specified in his CACM paper (at ftp://ftp.csua.berkeley.edu/pub/cypherpunks/papers/chaum.digital-mix.gz ), thus making them extremely vulnerable to anyone with non-trivial resources.) The simplifying assumptions I use here are: 1. there is one mix, which is perfectly secure and trustworthy (note that multiple mixes do not increase untracebility over a single mix if it is perfectly secure and trustworthy) 2. anyone can monitor all traffic in and out of the mix, but no one can link an incoming message with an outgoing one The basic approach is to use this raw traffic information to calculate a SCORE for each user of the remailer with respect to Alice, where the user with the highest SCORE is the person Alice is most probably communicating with. The idea is that with a Chaumian mix, every time Alice sends a message to Bob there is always a pattern of Alice sending a message to the mix, followed by Bob receiving a message from the mix during the next batch. By counting the number of such correlations for each user over a period of time, and taking into account the fact that users who receive more messages from the mix will have higher numbers of coincidental correlations, a SCORE can be calculated so that it would be a good indication over the long run of the probability that a particular user is communicating with Alice. For a digital mix that does batching based on a fixed number of incoming messages, the SCORE for a user U can be calculated in the following way: 1. for each mix batch i, calculate P(i)=lesser(# of messages sent by Alice, # of messages subsequently received by user U) 2. after a period of time t, calculate Q=sum(P(i)) 3. calculate the average value of Q of users with similar usage patterns as user U 4. SCORE(U) = Q / average(Q) Now whether or not this approach actually works depends on whether the number of users with SCORE higher than Bob's SCORE converges to 0 as time t increases, and how quickly it converges. Answering these two questions will require modeling the usage patterns of Alice, Bob, and the mix as a whole. I'll try to do this for some simple cases in a later post. Wei Dai -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLx9V8Tl0sXKgdnV5AQFg2gQAhEJ1wgf/XaqMOlVcvYfwgOeR2cKPPyQM fitAJdXKkEXvTtUa3biByvVK86SLQmW/0cLME76UsmaMUY+FVncBoKwlRGKJnDci 6b7VtEW2ZkZKntUieTXFaVbSgI5XL/lIqQu2FFS6wuxH1KayxFeDLiTD6HWfa8t6 sedGrTb5f2I= =Vjum -----END PGP SIGNATURE-----

1 0

Re: Threats in real life - what are we worried about?
by Matt Blaze 17 Dec '03

17 Dec '03

I wrote: > > Given existing crypto tools (PGP, etc), what are the top ten > practical attacks against the privacy of stored data and > electronic mail? Who are the bad guys? What tools do we need > to limit these threats? > >I'll post my own thoughts later. > Matt's Top Ten Underappreciated Threats to Privacy on the Internet ================================================================== 1. The sorry state of software. Everyone knows that nobody knows how to write software. Modern systems give hundreds of thousands of lines of code the chance to violate security policy. How can we be sure that the software we trust does the right thing? How can we reduce the opportunities for problems? 2. Ineffective protection against denial of service attacks. While not a direct threat to privacy, the ease with which almost anyone can mount effective denial of service attacks threatens the ability to deploy anonymous services. You'll note that no one worries very much about the millions of anonymous entry points to more robust networks like the telephone system or the postal service, where it's relatively hard (and expensive) for an individual to cause large-scale service disruption. How can we make the 'net robust enough to withstand mailbombs and newsgroup spamming? 3. Poor secret storage on networked computers. Cryptosystems allow you to manage large secrets by protecting smaller ones (keys). Unfortunately, modern computers are awful at protecting even the smallest secrets. Multi-user networked workstations can be broken into and their memories compromised. Standalone, single-user machines can be stolen or compromised through viruses that leak secrets asynchronously. What are the right mechanisms for storing and managing keys on various platforms? Remote servers, where there may be no user available to enter a passphrase (but see threat #5, below), are an especially hard problem. 4. Poorly understood random number generation techniques. Keys and session variables need good sources of unpredictable bits. Currently used techniques (like event inter-arrival times) are only marginally well understood and depend to a great deal on low-level characteristics of the platforms on which they are run. We need a wider range of techniques (especially ones that work without relying on user input), and to better understand their risks and failure modes. Some interesting ideas have been proposed that deserve further study. At CRYPTO '94 there was an interesting paper on using disk airflow variation to get random bits. Another interesting technique, first proposed by Don Mitchell, involves exploiting clock skew. Here's a C program that seems to produce one pretty random bit per second on most platforms. How good are the bits? Can we get more bandwidth out of it? #include <stdio.h> #include <signal.h> int count=0; void printbit() { signal(SIGALRM,printbit); alarm(1); printf("%1d",count&01); fflush(stdout); } main() { signal(SIGALRM,printbit); alarm(1); while (1) count++; } 5. Weak passphrases. Most crypto software addresses the key storage and key generation problems by relying on user-generated passphrase strings, which are presumed to contain enough entropy to produce good key material and are also easy enough to remember that they do not require secure storage. While dictionary attacks are a well known problem with short passwords, much less is known about lines of attack against user- selected passphrase-based keys. Shannon tells us that English text has just over 1 bit of entropy per character, which would seem to leave most passphrases well within reach of brute-force search. Less is known, however, about good techniques for enumerating passphrases in order to exploit low entropy. Until we have a better understanding of how to attack passphrases, we really have no idea how weak or strong they are. 6. Limited support for remote trusted agents. Almost all currently available cryptographic software assumes that the user is in direct control over the systems on which they run and has a secure path to it. For example, the interfaces to programs like PGP and CFS assume that their input is comes from the user over a secure path like the local console. This is not always the case, of course; consider the problem of reading your mail remotely when logged in over the Internet. We need better mechanisms for transferring the trusted operations to the local trusted machine while keeping the logical operations (like where the mail is) where they logically belong. 7. Poorly understood protocol and service interactions. Features frequently come back to bite us, and its hard to know even where to look. The Internet worm was propagated via an obscure and innocent-looking feature in sendmail; how many more features in how many more programs have unexpected consequences just waiting to be discovered? Is the conventional wisdom of hiding behind firewalls and turning off services really the only answer? 8. Lack of scalable security infrastructure. No comment... 9. Poorly understood "out of band" attack risks. Security people tend to focus on what's easy to model. Unfortunately, attackers focus on what's easy to exploit. We need a better understanding of just how easy some non-traditional attacks are. Most of the answers are probably too scary to think about. How long do our keys need to be in the face of electromagnetic radiation, physical monitoring, Trojan horses, social engineering, and so on and so on? 10. No broad-based demand for security. This is a well-known problem among almost everyone who has tied his or her fortune to selling security products and services. Until there is widespread demand for transparent security, the tools and infrastructure needed to support it will be expensive and inaccessible to many applications. This is partly a problem of understanding the threats and risks in real applications, and of building systems that include security as a basic feature rather than as a later "add on". There's a lot missing from this list, and a lot you can disagree with among the things that are on it. Flame away... -matt

1 0

RE: ELECTRONIC CASH ILLEG
by david.lloyd-jones＠canrem.com 17 Dec '03

17 Dec '03

Thomas Grant Edwards <tedwards(a)src.umd.edu> writes: TS+Actually, the "backing" of a fiat currency is the need to have some +around to pay your taxes, else you go to jail. You are taxed on many +types of income, even if they are not directly exchanged in the fiat +currency. Somehow you have to get some. This is pretty much true, but does not logically justify your conclusion: TS+This also means that higher taxes can make the currency more >desirable, +lower taxes less, higher government spending less, lower government +spending more, etc. This is only somewhat true. The most important factor is that currencies are traded on a fairly free market. This means supply and demand, not any firm intrinsic qualities of anything, dominate. If a country is running a positive net balance, whether by trade, capital investment, or influx of rich refugees, there will be a demand for its funnypaper, and that paper's price, in other currencies will rise. The same will apply to currencies not attached to countries -- such as the NetCredit, which I am working to put into reticulation. That's electronic for "circulation". :-) The hardest currencies, roughly in order, are those of Switzerland, Taiwan, and Japan. Germany is no longer on the list because Kohl bought the second last election in the most expensive bit of bribery in the history of democratic politics: the couple of trillion dollars he spent by assigning par value to the OstMark. Hong Kong is not on the list because of the huge outflows for the development of China, which tends to balance supply and demand at a lower/softer level than it would otherwise have. The US is no longer on the list because Reagan booted the whole thing into the can. Best, -dlj. -dlj. david.lloyd-jones(a)canrem.com * 1st 1.11 #3818 * Who won't do the arithmetic will live by stupid policies.

1 0

Remailer Software Sites/Comparison
by L. McCarthy 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Wei Dai writes: > Can anyone give an overview of the remailer packages that are currently > available? What features and differences do they have, and where to get > them? Raph Levien's Remailers WWW page has links to most of the material on the remailer software of which I'm aware: http://http.cs.berkeley.edu/~raph/remailer-list.html The remailer-help file from mixmaster(a)nately.ucsd.edu gives an ftp directory from which one may ultimately obtain Lance Cottrell's Mixmaster code, after following an export control process which I assume resembles MIT's method of distributing PGP. Lance sent out a first draft of instructions on the mixing (including packet splitting & recombination) features of Mixmaster to the list a few months ago, which I enclose below. Mixmaster is the latest and most sophisticated of the remailer packages I've seen, so I'd recommend it to anyone looking to install a new remailer in North America. - -L. Futplex McCarthy ===== forwarded message follows =============== Date: Sun, 20 Nov 1994 17:07:02 -0800 To: cypherpunks(a)toad.com, remailer-operators(a)c2.org Subject: 1st Draft Mixmaster chaining instructions Sender: owner-cypherpunks(a)toad.com Precedence: bulk X-Status: [...] Here is the first draft of the instructions for using Mixmaster to build remailer messages. I am posting it to give a flavor of what the program does, and to request comments, both on the features and on the clarity of the help file itself. Instructions for using Mixmaster to create type 2 remailer messages. I assume that you have either compiled Mixmaster, or that you have acquired a precompiled copy. While you do not need PGP to use Mixmaster, it is useful for key management, and is required if you desire security of the content of the message you are sending (which will be visible to the last remailer). Theory and purpose of remailers: The purpose of anonymous remailers (hereafter simply remailers), is to provide protection against traffic analysis. Traffic analysis is the study of who you are communicating with, when, and how often. This reveals more than you might expect about your activities. It will indicate who your friends and colleagues are (and they can be told apart by looking at the times you contact them). What your interests are, from which catalog companies you contact, and which ftp and WWW sites you visit. Traffic analysis can even reveal business secrets, e.g. your frequent contact with a rival could give hints of an impending merger. Remailers protect your email from traffic analysis. The original remailers did this by removing all headers, except the subject line, from any message you sent to them and then forwarding them a destination of your choice. The recipient of such a message would not know who had sent it. The addition of encryption to this scheme gave significant protection from attackers who simply look at passing messages for to and from fields. Passing a message through several remailers in a row is much better, but still vulnerable to an attacker who can watch messages go into and out of each remailer. Two more elements are required: messages must be reordered within the remailer before being forwarded (this is being done by a few of the old style remailers), and all messages must be indistinguishable. This last is the primary improvement with the type 2 remailer, Mixmaster. Using type 2 remailers: The trend towards ever more complicated remailer message formats has been clear for some time. Several programs have been written to automatically build messages which will be remailed by several remailers. This process is called chaining. With type 2 remailers it is no longer possible to create these messages by hand. Mixmaster takes a message you wish to send, a list of remailers to chain it through, and a final destination, and builds the packet which the remailers will use. For simplicity I will first describe the interactive use of Mixmaster, then I will discuss how it can be controlled through command line arguments. Interactive use of Mixmaster: If you run Mixmaster with no arguments, you will be prompted for all the required information. First you will be asked to specify the final destination of the message. This is the full email address where you want your message delivered. Remember that the message is being sent by the last remailer in the chain, so you must specify the full internet address (e.g. name(a)machine.place.com) you may not use local mail aliases. You may enter multiple recipients on separate lines. Hit return on a blank line to stop entering destinations. You must have at least one. Next you will be asked to enter any headers you want to have inserted before the message. These are those lines at the beginning of email messages, like From: fred(a)bedrock.univ.edu, or Subject: Party invitation. If you want your message to have a subject when it is delivered, you must enter a line Subject: your subject here. Note that Subject must be capitalized, with the : and space as shown. A subject header can be added by using the -s command line argument. When you are done entering headers, hit return (it is OK to have zero headers). You will now be presented with a list of remailers through which you can chain your messages. The order in which you choose them is the order in which they will be traversed by your message. You may choose up to 20 of them, but remember that the reliability and speed of the chain diminish as the number of remailers in the chain increases. Four is a reasonable number of remailers to use. It is fine to use a given remailer more than once in your chain. Press return on a blank line to stop entering remailers. Finally you will be asked what file you want to send. This must be an ASCII file. You may either enter the name of an existing file, or you may choose to enter the message directly by typing "stdin" as the file name. This is intended for use by scripts. There are no editing capabilities when using stdin. Enter the end of file character (EOF is ^D) when you are done entering the file. Mixmaster will now build the type 2 remailer packet, and send it to the first remailer in the chain. Command line arguments to Mixmaster: Mixmaster [-c] [in.filename] [-f] [-s "subject"] [-o "outfile"] [-to a(a)b.com] [-l 3 2 6 ...] -c this indicates that chaining rather than remailer functions are desired. It is a NOP since chaining is the default operation. "filename" if a filename is given, then this will be used as the input file. As in the interactive mode, you may choose "stdin". No filename will be prompted for. -f filter mode. All prompts suppressed, but input still accepted as described in the interactive section. The remailer list must be specified on the command line. -s "subject" Adds a subject line to the message. The user should NOT include Subject: in this string. Mixmaster will not prompt for other headers if -s is used. -o "outfile" Specify an output file rather than sending the message to the first remailer automatically. If outfile is "stdout", then the remailer packet will be printed to stdout. -to foo(a)bar.org specifies the final destination of the message. Only one destination can be specified. Mixmaster will not prompt for other destinations if -to is used. -l 4 3 5 ... Specifies the list of remailers to chain through. This must be the last argument on the command line. A maximum of 20 remailers may be specified. Mixmaster will not prompt for other remailers if -l is used. - -------------------------------------------------- Lance Cottrell who does not speak for CASS/UCSD loki(a)nately.ucsd.edu PGP 2.6 key available by finger or server. Encrypted mail welcome. Home page http://nately.ucsd.edu/~loki/ Home of "chain" the remailer chaining script. [...] - --- [This message has been signed by an auto-signing service. A valid signature means only that it has been received at the address corresponding to the signature and forwarded.] -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Gratis auto-signing service iQBFAwUBLx97BioZzwIn1bdtAQEMvQF/RlnlugSboXC/+LtZoyfVm4Blc4/do0re 59XYOo7Vs/AQRWLZU4iM8h65axpr7G3f =VW+M -----END PGP SIGNATURE-----

1 0

Netscape, RC4, key exchange?
by aba＠dcs.exeter.ac.uk 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- grendel(a)netaxs.com wrote: > aba(a)atlas.ex.ac.uk wrote: > > I have code to generate the RSA key pairs and modulus, what I am > > looking for is code to factorise a number using one of the better > > algorithms (quadratic sieve, etc.). > > It's been established that the encryption in Netscape is 40 bit >RC4, not 40 bit RSA, [...] Ok, so Netscape (the exported version only?) uses 40bit RC4 for encryption, but what about key exchange? RC4 is a stream cypher so both the receiver and sender need to know the key. Does anybody know what method Netscape uses to exchange keys DH, RSA, other? and what key sizes? Adam -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUALx+TkSnIuJ1VakpnAQEuBQP/TAiX81goT8r3KnvFh3WCm6TvzjUNAaEl G8NI5ELom8CWgIYp1uli+V+s0nRgZCKfZAvfeQrG97p2blSK0tOsZyV3E6cYKgXo yGcGUJZ8UdvBL0A93LJcU4LZEUITcC9/3HS09QD2oZBGzSettHk3nwKMmEer65OU QLsrRildnuw= =3vQF -----END PGP SIGNATURE-----

1 0

remailer questions
by Craig A. Johnston 17 Dec '03

17 Dec '03

Ok, I'm planning on putting up a remailer on my Linux box. One of the things I'd really like to know is, how much in the way of attempts to break into your machines are remailer ops seeing? How much in the way of other attacks? I'd also like to get some idea of the amt of resources consumed by a relatively popular remailer -- amt of system loading, disk space devoted to remailing activites, and anything else. I know loading will be hard to quantify in a meaningful way, but for reference my machine is a 486/66 w/32 megs RAM and pretty fast SCSI disks. Just a general idea of how significant the load on such a machine will be would be nice. My SCSI and Ethernet are both fast, and on a PCI bus. My site is at the moment, I think, relatively secure. I have few users and am sure at the moment nobody has an easily crackable password. I plant to install a fascist password checker soon. I currently have ftpd and fingerd commented out of my inetd.conf. (I plan to put ftpd back, at some point, but really don't like outsiders being able do a finger @site and find out who is on, how long, how long idle, find out when users last logged on or read their mail, etc. I will probably want to add it back after modifying it or finding a stock one that does what I want.) I have tcp wrappers installed, and have checked on a number of blatant security holes that I know of. I am worried that once I begin running a remailer, the number of attacks on my machine will increase dramatically. I'd of course like for my data and my users' data to remain private, and believe that a compromised remailer is (obviously) worse than no remailer at all. What would be nice, before I put up a remailer, would be to have any willing, security-knowledgeable cypherpunk subscribers out there to probe my machine for any really obvious chinks, for security-aware Linux users to point out any Linux or Slackware-specific security holes, etc. Of course I'd want to have a word with anyone willing to probe me before they just went at it... ;) Linux kernel is currently 1.1.81, which is quite stable for me, and the Slackware distribution is 1.2.0. I'm running sendmail 8.6.9, are there any really terrible vulnerabilities in it any longer from outside the machine? From inside? Of course, I'm on an Ethernet with others, and have users logging in from other Ethernets, so am vulnerable to sniffers. I don't think it's going to be feasible to install skey here, as a number of my users are extremely non-technical. I'm also still looking around for what I'm going to run. I'd like for it to be easy to reply to users, but absolutely impossible for me to 'out' anyone under any circumstances. The encrypted-sender stuff some remailers currently use is probably too ugly for most average joes to want to use, and not as secure as I'd like. It's probably the best available at the moment. This should definitely change. What I'd *really* like to do would be to write a client and server to make an anonymous pool act like normal email ... this is really the only way I can think of to make replying easy but also to have good security. I'm sort of surprised someone has not done this yet. It'd be pseudonymous, your client would only look at messages for you or for everyone (for your convenience -- of course anyone could look at anything, but it'll all be PGP'ed, so...) Some really neat things that could be done w/this... for folks willing to trust the sever to some degree, cross-referencing of pseudonyms and public keys could be done, allowing joe user to just mail to a pseudonym -- this would be good in cases where one party wishes to hide, while the other has nothing to hide and is possibly very non-technical. He'd have no guarantee that someone wasn't reading his mail to the pseudonymous party, on the way in, but the p.n. party would not have to worry about having his real address cross-referenced, or about the server having the key to decrypt his real (included) address in memory or on disk. Anon pools are obviously doable right now, with a mailing list, but the inconvenience of using one like this is a real barrier. An anonymous pool; Usenet-like -- distributed over many machines in many countries, but with pseudonyms instead of "real names" and public keys as addresses. This is definitely doable, right now. NNTP-type servers doing news and mail service. As the scale got larger, we'd of course not want to send everyone's mail to all the servers, but tying a user down only as far as to a given server would probably not be a problem -- look at all the different folks that may use one NNTP server. Perhaps mail for a given user could be sent to several different servers to keep things muddy. Mixmaster does not currently run on Linux, is that correct? Anyone know what the problem is, or have an idea what amt of work would be involved in porting it? I'd like to look at this. Really, though, everything out there is pretty unsatisfactory -- only anonymous pools and DC-nets have the characteristics I'm interested in. Anyone on the list doing any serious work on DC-nets? I find these extremely exciting, and don't see much brainstoming on implementation going on. regards, Craig.

1 1

Re: T.A.Z. on Disk
by Angus Patterson 17 Dec '03

17 Dec '03

On Fri, 20 Jan 1995, Charles Bell wrote: > > > > The book "Temporary Autonomous Zone" is available online at wiretap.spies.com > > Available how, exactly? Sorry about that. The hazards of being brief, I guess (never post when you're half asleep). Gopher and ftp work for the same address on this one. /Library/Documents/taz.txt is good for ftp, or try the /Electronic Books at Wiretap heading on the first menu, if you use gopher. The pointers to the other etext sites might lead you to his other stuff (there were two others as far as I can remember).

1 0

Crypto Anarchy/Libertarians in WSJ
by frissell＠panix.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Today's WSJ Front Page Left Column Less Is More Libertarian Impulses Show Growing Appeal Among the Disaffected When the Government Fails Many Voters are Asking: Who Needs it Anyway? Mixed Blessing to the GOP "Mr. Frezza...doesn't just want to cut government: He questions the very need for most of it. He figures that in a world in which computer wizards are close to creating their own private, encrypted digital cash system for making transactions without any government involvement, the need for centralized authority is shrivling." DCF -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBLx/FiIVO4r4sgSPhAQEhmgP/dxCXAPS6iu/Zb9P7AuC6D8aDg94vZABs VjlXXXXWjkHedveIjQ9qdU8xELblzZiMlu35SKKygLvsD2a8bNXiC2FxBnA/H716 Dj4UHksctV3wJSZuwq6z8/fZds0Dg5GJLYbAUrbdInp/tM7TMrAhUVLFVkVpzhzk 25aXzmIiv5U= =4FOR -----END PGP SIGNATURE----- ************************************************************************* ATMs, Contracting Out, Digital Switching, Downsizing, EDI, Fax, Fedex, Home Workers, Internet, Just In Time, Leasing, Mail Receiving, Phone Cards, Quants, Securitization, Temping, Voice Mail.

1 0

Re: T.A.Z. on Disk
by dmandl＠bear.com 17 Dec '03

17 Dec '03

> From: blancw(a)pylon.com > > *T.A.Z. = The Autonomous Zone T.A.Z. = Temporary Autonomous Zone --Dave.

1 0