December 2003 - cypherpunks-legacy

Complete Waste of Bandwidth
by Robert A. Hayden 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- As you may remember, I wrote the Geek Code. Well, for those that care, run on out and pick up the April 18th issue of Rolling Stone (it has a 1/2 naked guy on the cover) and take a gander at page 20. It's and article about yours truly and the Geek Code. Cool, eh? *grin* -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: PGP Signed with PineSign 2.2 iQCVAwUBMWB2LjokqlyVGmCFAQEX4gP/TRTZjtPrlF0mD6gGwz/qyc1+dQpzP/ae T9H/jojqSxX5o1BYC1DEQQtAW/K28VKMRvaAlx7tqIxMvNPyVHGIcDqSovzTDo8C D5P79xQR+NGuzWZFaOsIOT89vWw3JF8nw8ug2oqQIxlwqWqqk9ju6JRa+yywC6K9 xlAIYiDK3XM= =+X1Q -----END PGP SIGNATURE----- ____ Robert A. Hayden <=> hayden(a)krypton.mankato.msus.edu \ /__ Finger for Geek Code Info <=> Finger for PGP Public Key \/ / -=-=-=-=-=- -=-=-=-=-=- \/ http://krypton.mankato.msus.edu/~hayden/Welcome.html -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GED/J d-- s:++>: a- C++(++++)$ ULUO++ P+>+++ L++ !E---- W+(---) N+++ o+ K+++ w+(---) O- M+$>++ V-- PS++(+++)>$ PE++(+)>$ Y++ PGP++ t- 5+++ X++ R+++>$ tv+ b+ DI+++ D+++ G+++++>$ e++$>++++ h r-- y+** ------END GEEK CODE BLOCK------

1 0

Re: What backs up digital money?
by FRank O. Trotter, III 17 Dec '03

17 Dec '03

Quite a time to go on vacation and have the power supply to my laptop first show wires then break! A great series of rants about the backing of ecash, and I missed most of it (at least in real time). I'll add a few of my thoughts and see if it all goes any further. Ecash is a means of transferring value, currently USD at Mark Twain, betweeen parties. Ecash, however denominated, is not a currency in itself. Any "currency" or other "value units", be it USD, DEM, gold, silver, coupons, etc can be transferred by the ecash system. The Mint licensee must agree and then issue the units. This is, after all, software. The value unit or currency has value because people agree it has value. CyberBucks were (and still are) somewhat convertable to tangible goods - they are for sure convertable to intrinsic goods as demonstrated by the CyberBucks trial. USD and DEM have value only because we all accept them as payment - as fiat currencies there is no formal backing. Gold has value because ... One of the keys in any system is that users feel comfortable about the future value of the units or currency, be the units a national currency, a commodity, or a coupon. There are two components to this: 1) The user must believe that they will receive the units back from someone at a later date - this is plain old fashion credit risk. For example if I am running an ecash system with gold then you have to believe that I will give you gold upon request - same for USD and this is why banks for the time being should be the primary issuer to avoid a general credit risk. If users are unsure or unable to determine if the Mint operator will return the nominal value of the units then there is not enough confidence to run a system. Consider pre-FDIC days in US banking. 2) The user must believe that the units will have a value in the future. We can agree that FOT Units are each worth US$1.0 million today, but how will their value be determined tomorrow? Non-national currency, however attractive from a theoretical standpoint is weak under this guideline. I am a strong believer that ecash will support many national currencies, commodity based implementations such as gold and silver, as well as coupons and commercial equivalents. Use of ecash for payments will depend only on the creative uses presented by someone willing to sell at a profit a product that attracts customers. There is likely some point where a non-national currency will become attractive first to the internet community, then to the public at large. If done with low credit risk it can survive. You should consider that two of the key elements to determine value are precisely known in ecash and not in circulating money - money supply and velocity. One now has only to consider other factors like purchasing power to obtain a base value. Ecash puts banks back into the business of being banks - acting as a storehouse of value, and as a means to transfer this value, all for a fee. The early bank models were exclusively along these lines, with the various lending and investing functions added later. All for now, a start anyway. FOT Disclaimer - Personal not corporate thoughts. Frank O. Trotter, III - fotiii(a)crl.com www.marktwain.com - Fax: +1 314 569-4906 --------------------------------------------

1 0

Re: ACM/IEEE Letter on Crypto
by jim bell 17 Dec '03

17 Dec '03

At 04:24 PM 4/1/96 -0500, Dave Banisar wrote: > Association For Computing Machinery [address deleted] > Institute of Electronics and Electrical Engineers [address deleted] >April 2, 1996 [thank heavens it wasn't April 1!] >Honorable Conrad Burns >Chairman, Subcommittee on Science, Technology and Space [etc] >Dear Chairman Burns: > > On behalf of the nation's two leading computing and engineering >associations, we are writing to support your efforts, and the efforts of >the other cosponsors of the Encrypted Communications Privacy Act, to >remove unnecessarily restrictive controls on the export of encryption >technology. The Encrypted Communications Privacy Act sets out the >minimum changes that are necessary to the current export controls on >encryption technology. However, we believe that the inclusion of issues >that are tangential to export, such as key escrow and encryption in >domestic criminal activities, is not necessary. The relaxation of >export controls is of great economic importance to industry and users, >and should not become entangled in more controversial matters. As far as it goes, and considering that it's from an industry group, this sounds like an excellent response to this Burns bill proposal. (Not "Bill," because it's still not available, apparently.) This response is probably as close as we can expect to a repudiation of the Leahy bill. It still isn't clear, though, whether the Burns bill is intended to be just an elimination of export controls on encryption, or whether it will contain other provisions. My question, which still hasn't been answered, is: "Does this bill exist yet?" The answer is really not inconsequential, because if it _isn't_ at least sketched out yet, then that either should give us the opportunity to add provisions we want, or alert us that there is still the risk from Denning-types of including provisions we don't want. Either way, action is called for, if only action to keep somebody else from taking action. I don't have any objection to a bill which merely eliminates export requirements on encryption; that would be a substantial step in the proper direction. If that's the best we can do for this session of Congress, I hope we can achieve this as a stepping-stone. Jim Bell jimbell(a)pacifier.com

1 0

Re: New release of SFS available
by David K. Merriman 17 Dec '03

17 Dec '03

At 09:07 PM 04/1/96 -0500, Tim Scanlon <tfs(a)vampire.science.gmu.edu> wrote: ^^^^^^^ >pgut001(a)cs.auckland.ac.nz >> >> I have just uploaded version 1.19 of SFS to the grumbo.uwasa.fi FTP site as: ... >> The head of the FBI Louis Freeh has been quoted as saying that "this will >> provide adequate protection against your little sister or your mother, while >> allowing law enforcement agencies to investigate people using encryption for >> illegal purposes". The head of the French DSSI agrees: "There have been too >> many cases of industrial espionage by foreign government intelligence agencies. > >Remind me not to use this junk. Ever. Got one! Reeeeeeeeel 'im in! ROFLMAO Dave Merriman ------------------------------------------------------------- "Giving money and power to government is like giving whiskey and car keys to teenage boys." P. J. O'Rourke (b. 1947), U.S. journalist. <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> http://www.shellback.com/personal/merriman/index.htm

1 0

List of reliable remailers
by Raph Levien 17 Dec '03

17 Dec '03

I operate a remailer pinging service which collects detailed information about remailer features and reliability. To use it, just finger remailer-list(a)kiwi.cs.berkeley.edu There is also a Web version of the same information, plus lots of interesting links to remailer-related resources, at: http://www.cs.berkeley.edu/~raph/remailer-list.html This information is used by premail, a remailer chaining and PGP encrypting client for outgoing mail. For more information, see: http://www.c2.org/~raph/premail.html For the PGP public keys of the remailers, finger pgpkeys(a)kiwi.cs.berkeley.edu This is the current info: REMAILER LIST This is an automatically generated listing of remailers. The first part of the listing shows the remailers along with configuration options and special features for each of the remailers. The second part shows the 12-day history, and average latency and uptime for each remailer. You can also get this list by fingering remailer-list(a)kiwi.cs.berkeley.edu. $remailer{"extropia"} = "<remail(a)miron.vip.best.com> cpunk pgp special"; $remailer{"portal"} = "<hfinney(a)shell.portal.com> cpunk pgp hash"; $remailer{"alumni"} = "<hal(a)alumni.caltech.edu> cpunk pgp hash"; $remailer{"bsu-cs"} = "<nowhere(a)bsu-cs.bsu.edu> cpunk hash ksub"; $remailer{"c2"} = "<remail(a)c2.org> eric pgp hash reord"; $remailer{"penet"} = "<anon(a)anon.penet.fi> penet post"; $remailer{"hacktic"} = "<remailer(a)utopia.hacktic.nl> cpunk mix pgp hash latent cut post ek"; $remailer{"flame"} = "<remailer(a)flame.alias.net> cpunk mix pgp. hash latent cut post reord"; $remailer{"rahul"} = "<homer(a)rahul.net> cpunk pgp hash filter"; $remailer{"mix"} = "<mixmaster(a)remail.obscura.com> cpunk mix pgp hash latent cut ek ksub reord ?"; $remailer{"ford"} = "<remailer(a)bi-node.zerberus.de> cpunk pgp hash ksub ek"; $remailer{"vishnu"} = "<mixmaster(a)vishnu.alias.net> cpunk mix pgp hash latent cut ek ksub reord"; $remailer{"robo"} = "<robo(a)c2.org> cpunk hash mix"; $remailer{"replay"} = "<remailer(a)replay.com> cpunk mix pgp hash latent cut post ek"; $remailer{"spook"} = "<remailer(a)spook.alias.net> cpunk mix pgp hash latent cut ek reord"; $remailer{"rmadillo"} = "<remailer(a)armadillo.com> mix cpunk pgp hash latent cut ek"; $remailer{"ecafe"} = "<cpunk(a)remail.ecafe.org> cpunk mix"; $remailer{"wmono"} = "<wmono(a)valhalla.phoenix.net> cpunk mix pgp. hash latent cut"; $remailer{"shinobi"} = "<remailer(a)shinobi.alias.net> cpunk mix hash latent cut ek reord"; $remailer{"amnesia"} = "<amnesia(a)chardos.connix.com> cpunk mix pgp hash latent cut ksub"; $remailer{"gondolin"} = "<mix(a)remail.gondolin.org> cpunk mix pgp hash latent cut ek reord"; $remailer{"tjava"} = "<remailer(a)tjava.com> cpunk mix pgp hash latent cut"; $remailer{"pamphlet"} = "<pamphlet(a)idiom.com> cpunk pgp hash latent cut ?"; $remailer{'alpha'} = '<alias(a)alpha.c2.org> alpha pgp'; $remailer{'gondonym'} = '<alias(a)nym.gondolin.org> alpha pgp'; $remailer{'nymrod'} = '<nymrod(a)nym.alias.net> alpha pgp'; $remailer{'cubed'} = '<alias(a)alias.alias.net> alpha pgp'; $remailer{"lead"} = "<mix(a)zifi.genetics.utah.edu> cpunk pgp hash latent cut ek"; $remailer{"treehole"} = "<remailer(a)mockingbird.alias.net> cpunk pgp hash latent cut ek"; $remailer{"nemesis"} = "<remailer(a)meaning.com> cpunk pgp hash latent cut"; $remailer{"exon"} = "<remailer(a)remailer.nl.com> cpunk pgp hash latent cut ek"; $remailer{"vegas"} = "<remailer(a)vegas.gateway.com> cpunk pgp hash latent cut"; $remailer{"haystack"} = "<haystack(a)holy.cow.net> cpunk pgp hash latent cut ek"; $remailer{"ncognito"} = "<ncognito(a)gate.net> mix cpunk latent"; catalyst(a)netcom.com is _not_ a remailer. lmccarth(a)ducie.cs.umass.edu is _not_ a remailer. usura(a)replay.com is _not_ a remailer. Groups of remailers sharing a machine or operator: (c2 robo alpha) (gondolin gondonym) (flame hacktic replay) (alumni portal) (vishnu spook wmono nymrod) Use "premail -getkeys pgpkeys(a)kiwi.cs.berkeley.edu" to get PGP keys for the remailers. Fingering this address works too. Note: The remailer list now includes information for the alpha nymserver. Last update: Mon 1 Apr 96 6:48:11 PST remailer email address history latency uptime ----------------------------------------------------------------------- ecafe cpunk(a)remail.ecafe.org -*#*######## :48 100.00% haystack haystack(a)holy.cow.net *-##+*****+* 2:09 100.00% cubed alias(a)alias.alias.net ***+#** 19:29 99.99% pamphlet pamphlet(a)idiom.com ++++++++++-+ 1:22:18 99.99% nymrod nymrod(a)nym.alias.net +++--*+*+--* 38:14 99.98% nemesis remailer(a)meaning.com **++******** 17:30 99.97% flame remailer(a)flame.alias.net .---.------ 5:25:05 99.97% shinobi remailer(a)shinobi.alias.net #*########*# 1:07 99.97% hacktic remailer(a)utopia.hacktic.nl ****+******* 8:11 99.97% alpha alias(a)alpha.c2.org ++++-++++**+ 46:53 99.92% vegas remailer(a)vegas.gateway.com .-*.-#*#+### 4:28:59 99.89% ncognito ncognito(a)gate.net #*# ##***-## 6:36 99.72% mix mixmaster(a)remail.obscura.com -+-___.--*-* 15:11:14 99.69% spook remailer(a)spook.alias.net +***+*+**+** 19:46 99.66% gondolin mix(a)remail.gondolin.org __.--*----- 13:53:43 99.64% gondonym alias(a)nym.gondolin.org __.--*--+-- 13:48:57 99.64% exon remailer(a)remailer.nl.com --***++**-* 13:59 99.59% replay remailer(a)replay.com ++**++*+**+ 8:46 99.57% vishnu mixmaster(a)vishnu.alias.net ++- - ***--+ 2:46:31 99.26% treehole remailer(a)mockingbird.alias.net --+++-- -+++ 3:47:33 98.96% amnesia amnesia(a)chardos.connix.com -- --+--+++ 1:57:42 98.49% portal hfinney(a)shell.portal.com *#-#####*## 1:30 96.59% alumni hal(a)alumni.caltech.edu _* #+# -### 1:08:06 96.24% penet anon(a)anon.penet.fi .___ -__.. 47:32:06 95.78% c2 remail(a)c2.org *****.+-+++ 37:24 94.43% extropia remail(a)miron.vip.best.com --------- 6:03:31 83.40% lead mix(a)zifi.genetics.utah.edu *+++++ 34:15 34.40% tjava remailer(a)tjava.com #* ** 1:02 25.24% History key * # response in less than 5 minutes. * * response in less than 1 hour. * + response in less than 4 hours. * - response in less than 24 hours. * . response in more than 1 day. * _ response came back too late (more than 2 days). cpunk A major class of remailers. Supports Request-Remailing-To: field. eric A variant of the cpunk style. Uses Anon-Send-To: instead. penet The third class of remailers (at least for right now). Uses X-Anon-To: in the header. pgp Remailer supports encryption with PGP. A period after the keyword means that the short name, rather than the full email address, should be used as the encryption key ID. hash Supports ## pasting, so anything can be put into the headers of outgoing messages. ksub Remailer always kills subject header, even in non-pgp mode. nsub Remailer always preserves subject header, even in pgp mode. latent Supports Matt Ghio's Latent-Time: option. cut Supports Matt Ghio's Cutmarks: option. post Post to Usenet using Post-To: or Anon-Post-To: header. ek Encrypt responses in reply blocks using Encrypt-Key: header. special Accepts only pgp encrypted messages. mix Can accept messages in Mixmaster format. reord Attempts to foil traffic analysis by reordering messages. Note: I'm relying on the word of the remailer operator here, and haven't verified the reord info myself. mon Remailer has been known to monitor contents of private email. filter Remailer has been known to filter messages based on content. If not listed in conjunction with mon, then only messages destined for public forums are subject to filtering. Raph Levien

1 0

RE: Witch hunt
by Brian D Williams 17 Dec '03

17 Dec '03

>From: "Vladimir Z. Nuri" <vznuri(a)netcom.com> >Tim May == Rousseau??? hehehehehe. and I fail to comprehend how >anyone so universally despised as Detweiller could be considered >to have employed any "effective critical technique". maybe I >should send him some email, but alas I perceive that to be another >waste of time. Send HIM some E-mail? That's pretty funny Larry! What happened, someone sever your Corpus Callosum? Brian

1 0

gnutar + pgp filter mode
by William Hayward 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- The gnu tar archiver allows to use an arbitrary compression program (option --use-compress-program=PROG). This works well with pgp if a small wrapper is used: #!/bin/csh -fb if ("$1" == "-d") then exec pgp -d -f else exec pgp -e -f endif The only problem is that this doesn't work well for larger amounts of data, because pgp reads in all data before starting with its work. Perhaps a future release of pgp will have a real filter mode. Hadmut BTW: Does this "crypto-hook" cause export restrictions to apply on gtar ? -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMV/0tmc1jG5vDiNxAQFtAAP/TMuYeYf5q7k1Y8DrBjb6XFKYYFANH3RH FvThWq1BUgI+unH97EZkNkCzZJYT5qmLGk3+JLufCAw/o9YR7jKcldm2LNYJ96t2 BDcSGDF3qx/IUzQBa5NV+gUerNRVSwA3LzkTbXufOxYH0cB3KNcsx3B0bE1rEDa/ GCcJ1L6T+2s= =FMiZ -----END PGP SIGNATURE-----

1 0

"Dead beef" attack against PGP's key management
by Raph Levien 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- This post is signed by a forged key for Phil Zimmermann. I forged the key this morning. The key has the same user id and visible key id as an old key for Phil Zimmermann, which he has since revoked. I should stress that this attack does not in any way weaken the security of PGP's message formats. However, it does expose a problem in the user interface of its key management. Namely, it is fairly easy to forge a key that looks very similar to an existing key. In fact, the only way to distinguish between real and forged keys in general is by the fingerprint and keysize together. My purpose in posting this is to demonstrate that such forgeries are possible. The lesson is: please do not use the key id alone to identify keys. Another reason for the public posting of this forgery is to goad the PGP development team into improving the user interface in PGP 3.0, so as to make the detection of such a forgery much easier, if not routine. Derek Atkins has assured me that PGP 3.0 will include a cryptographic hash of the key, for use as a key id. If implemented properly, such a facility would address this attack. I am not the first to propose this attack. According to Derek Atkins, Paul Leyland first proposed the attack two years ago. Also, Greg Rose successfully mounted a similar attack six months ago, creating a key with user id 0xDEADBEEF, thereby giving rise to the name. The pseudocode for the attack is as follows: choose random 512 bit prime p choose random 480 odd x q = x * ((0xdeadbeef * (p * x) ^ -1) mod 2^32) do {q += 2^32} while q composite The above bit of pseudocode replaces the original selection of p and q, which are normally just random 512 bit primes. Without having done detailed analysis, I believe that the resulting forged keys are just as good as ordinary PGP keys. Further, the modified key generation is almost as fast as ordinary PGP key generation, and I think I could speed it up a bit more. The attack took me a few hours to design and code. Any good programmer familiar with PGP could duplicate it easily. One practical application of this attack is to implement a certain degree of "stealth." Since PGP includes the key id in encrypted messages, it is in most cases possible to identify the recipients of encrypted messages. However, if a lot of people generated keys with the same key id, then it would not be possible to tell from the encrypted message which one was the intended recipient. Here's the public key I forged, which can be used to check the signature of this message: Key for user ID: Philip R. Zimmermann <prz(a)acm.org> 1024-bit key, Key ID FF67F70B, created 1992/07/22 Also known as: Philip R. Zimmermann <prz(a)sage.cgd.ucar.edu> - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAyptNMAAAAEEALRhS3ZCFKLPNF/fZeluh/rNfpgZ5a0ddTBtxJ+1yLIkVurb HWFFBsrmnA4hU4MhlA8DS/f2gnS0v3zyQ78JOY1SBIJrLdaIPIrh0ZTAZXWoQWDe Qknm1ZgyLkIRJlt5aDLp+iLJ5sc+LSO5N/DtrL+Htc5MF0AVAWtzPhz/Z/cLAAUR tCJQaGlsaXAgUi4gWmltbWVybWFubiA8cHJ6QGFjbS5vcmc+iQCVAwUQMWAremtz Phz/Z/cLAQE//AP/bg9gMOuiBYkFCiyarJ/DIARWDf7e4bWFJloXAyPeBXCITDIw tuHRJ41yFqnlLmdcuVhXQf/xrH248JyWpHqqED6eOU/PnBHo9IR6H0Fts+O3I+vk tOYRjuTJy+6JV0s/8VN/Sgh8y6Jm2FGhhzhCp6KHNcTHpUud6iGScaEs/CG0LFBo aWxpcCBSLiBaaW1tZXJtYW5uIDxwcnpAc2FnZS5jZ2QudWNhci5lZHU+ =Z1mf - -----END PGP PUBLIC KEY BLOCK----- Raph Levien -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMWA2pGtzPhz/Z/cLAQELEQP/fam4tHS8TlMy7SFoUZvC0C4q0ID9Ze5W rY2D++df4UtAFDITGs4lQqzeq6YCqk51oT8gZAACK6D6UlFgr5roIbgwa74Fxso1 B5mquC9axlOlxZJI1PuK+NflBJqCokuQGtG95ER6vbm4n4RACW43In9SAatIvduN JfBSLYrAr14= =V5U6 -----END PGP SIGNATURE-----

1 0

Re: Electronic locksmiths are watching you (Belgium's ban onPGP)
by jim bell 17 Dec '03

17 Dec '03

At 02:56 PM 4/1/96 -0500, Black Unicorn wrote: > >Following my new policy on Jim Bell posts, the below represents my new >form of reply. These 'terse' replies should cut down on bandwidth and >still serve as some basic protection to the list readership as to the >mis and dis-information which eminates in quantity from Mr. Bell's >account. Those parties interested in a more detailed discussion, aside >of course Mr. Bell, should ask for clarification where they feel it >necessary and I will then expound on my points. What you _really_ ought to do is to cut down your responses to ZERO, especially on material that was not sent to you. Until you're willing to talk intelligently about what you believe, you're just wasting peoples' time. Jim Bell jimbell(a)pacifier.com

1 0

Re: "Random Sequence"
by rollo＠artvark.com 17 Dec '03

17 Dec '03

>At 07:25 AM 3/31/96 -0700, Rollo Silver wrote: >>The paper "On the Effective Definition of 'Random Sequence'", by Michael >>Levin, Marvin Minsky, and Roland Silver can be viewed (and downloaded, and >>printed) from my website <http://www.artvark.com/artvark>. > >Rollo, > > I read the paper and it's nice work -- but it departs from current >definitions of random sequences in that it assumes you specify the countable >set of machines trying to test for non-randomness first and then generate a >sequence to fool that set of machines. Current definitions of randomness >assume an infinite set of testing machines, often limited to polynomial time >and space, and a sequence generator that must defeat them all without >knowing anything about them. Such sequences are, in a sense, "more random" >than the ones your paper dealt with -- I believe. Did I miss something? * It's a bit anachronistic to say in 1996 that a paper written 30 years earlier "departs from current definitions of random sequences." The authors may have been brilliant, but they weren't prescient. <g> I can't imagine how a computer could be smart enough to defeat an infinite set of guessing machines without knowing ANYTHING about them. In fact, what's wrong with this argument: call the "fooling" machine Frank, and one of the "guessing" machine Gert. You say that Frank doesn't need to know anything about Gert. Let me suppose however that Gert DOES know about Frank. In that case, Gert can simulate Frank and "guess" his output, thus foiling Frank's attempts to fool Gert! Maybe it's the "polynomial time & space". That restricts the guesser-domain considerably, compared with our very weak requirement that the guessers can be any Turing machines whatever -- as long as the set of them is effectively calculable. BTW, is the set of ALL finite automata effectively calculable? I suspect maybe so. If so, by essentially the argument given in the paper, there is a computer (Turing machine) that can fool them ALL. I hope it's okay to cc this note to coderpunks. It's not about coding per se, but it may shed some light on what "randomness" means, and on "computable randomness", which sounds appropriate for coderpunks to me. ------------------------------------------------------------------------ Rollo Silver | The CDA means | Artvark / PO Box 219 505-586-0197 | lost jobs and | San Cristobal, NM 87564 USA rollo(a)artvark.com | dead teenagers | http://www.artvark.com/artvark/

1 0