December 2003 - cypherpunks-legacy

Welcome to cypherpunks
by Majordomo＠toad.com 17 Dec '03

17 Dec '03

-- Welcome to the cypherpunks mailing list! If you ever want to remove yourself from this mailing list, you can send mail to "Majordomo(a)toad.com" with the following command in the body of your email message: unsubscribe cypherpunks Cypherpunks Mailing List <cypher(a)infinity.nus.sg> Here's the general information for the list you've subscribed to, in case you don't already have it: About cypherpunks ----------------- I. Administrivia (please read, boring though it may be) The cypherpunks list is a forum for discussing personal defenses for privacy in the digital domain. It is a high volume mailing list. If you don't know how to do something, like unsubscribe, send mail to majordomo(a)toad.com and the software robot which answers that address will send you back instructions on how to do what you want. If you don't know the majordomo syntax, an empty message to this address will get you a help file, as will a command 'help' in the body. Even with all this automated help, you may still encounter problems. If you get really stuck, please feel free to contact me directly at the address I use for mailing list management: cypherpunks-owner(a)toad.com Please use this address for all mailing list management issues. Hint: if you try to unsubscribe yourself from a different account than you signed up for, it likely won't work. Log back into your old account and try again. If you no longer have access to that account, mail me at the list management address above. Also, please realize that there will be some cypherpunks messages "in transit" to you at the time you unsubscribe. If you get a response that says you are unsubscribed, but the messages keep coming, wait a day and they should stop. For other questions, my list management address is not the best place, since I don't read it every day. To reach me otherwise, send mail to eric(a)remailer.net This address is appropriate for emergencies (and wanting to get off the list is never an emergency), such as the list continuously spewing articles. Please don't send me mail to my regular mailbox asking to be removed; I'll just send you back a form letter. Do not mail to the whole list asking to be removed. It's rude. The -request address is made exactly for this purpose. To post to the whole list, send mail to cypherpunks(a)toad.com If your mail bounces repeatedly, you will be removed from the list. Nothing personal, but I have to look at all the bounce messages. There is no digest version available. There is an announcements list which is moderated and has low volume. Announcements for physical cypherpunks meetings, new software and important developments will be posted there. Mail to cypherpunks-announce-request(a)toad.com if you want to be added or removed to the announce list. All announcements also go out to the full cypherpunks list, so there is no need to subscribe to both. II. About cypherpunks The cypherpunks list is not designed for beginners, although they are welcome. If you are totally new to crypto, please get and read the crypto FAQ referenced below. This document is a good introduction, although not short. Crypto is a subtle field and a good understanding will not come without some study. Please, as a courtesy to all, do some reading to make sure that your question is not already frequently asked. There are other forums to use on the subject of cryptography. The Usenet group sci.crypt deals with technical cryptography; cypherpunks deals with technical details but slants the discussion toward their social implications. The Usenet group talk.politics.crypto, as is says, is for political theorizing, and cypherpunks gets its share of that, but cypherpunks is all pro-crypto; the debates on this list are about how to best get crypto out there. The Usenet group alt.security.pgp is a pgp-specific group, and questions about pgp as such are likely better asked there than here. Ditto for alt.security.ripem. The cypherpunks list has its very own net.loon, a fellow named L. Detweiler. The history is too long for here, but he thinks that cypherpunks are evil incarnate. If you see a densely worded rant featuring characteristic words such as "medusa", "pseudospoofing", "treachery", "poison", or "black lies", it's probably him, no matter what the From: line says. The policy is to ignore these postings. Replies have never, ever, not even once resulted in anything constructive and usually create huge flamewars on the list. Please, please, don't feed the animals. III. Resources. A. The sci.crypt FAQ anonymous ftp to rtfm.mit.edu:pub/usenet-by-group/sci.crypt The cryptography FAQ is good online intro to crypto. Very much worth reading. Last I looked, it was in ten parts. B. cypherpunks ftp site anonymous ftp to ftp.csua.berkeley.edu:pub/cypherpunks This site contains code, information, rants, and other miscellany. There is a glossary there that all new members should download and read. Also recommended for all users are Hal Finney's instructions on how to use the anonymous remailer system; the remailer sources are there for the perl-literate. C. Bruce Schneier's _Applied Cryptography_, published by Wiley This is required reading for any serious technical cypherpunk. An excellent overview of the field, it describes many of the basic algorithms and protocols with their mathematical descriptions. Some of the stuff at the edges of the scope of the book is a little incomplete, so short descriptions in here should lead to library research for the latest papers, or to the list for the current thinking. All in all, a solid and valuable book. It's even got the cypherpunks-request address. IV. Famous last words My preferred email address for list maintenance topics only is hughes(a)toad.com. All other mail, including emergency mail, should go to hughes(a)ah.com, where I read mail much more regularly. Enjoy and deploy. Eric ----------------------------------------------------------------------------- Cypherpunks assume privacy is a good thing and wish there were more of it. Cypherpunks acknowledge that those who want privacy must create it for themselves and not expect governments, corporations, or other large, faceless organizations to grant them privacy out of beneficence. Cypherpunks know that people have been creating their own privacy for centuries with whispers, envelopes, closed doors, and couriers. Cypherpunks do not seek to prevent other people from speaking about their experiences or their opinions. The most important means to the defense of privacy is encryption. To encrypt is to indicate the desire for privacy. But to encrypt with weak cryptography is to indicate not too much desire for privacy. Cypherpunks hope that all people desiring privacy will learn how best to defend it. Cypherpunks are therefore devoted to cryptography. Cypherpunks wish to learn about it, to teach it, to implement it, and to make more of it. Cypherpunks know that cryptographic protocols make social structures. Cypherpunks know how to attack a system and how to defend it. Cypherpunks know just how hard it is to make good cryptosystems. Cypherpunks love to practice. They love to play with public key cryptography. They love to play with anonymous and pseudonymous mail forwarding and delivery. They love to play with DC-nets. They love to play with secure communications of all kinds. Cypherpunks write code. They know that someone has to write code to defend privacy, and since it's their privacy, they're going to write it. Cypherpunks publish their code so that their fellow cypherpunks may practice and play with it. Cypherpunks realize that security is not built in a day and are patient with incremental progress. Cypherpunks don't care if you don't like the software they write. Cypherpunks know that software can't be destroyed. Cypherpunks know that a widely dispersed system can't be shut down. Cypherpunks will make the networks safe for privacy. [Last updated Mon Feb 21 13:18:25 1994]

1 0

No Subject
by floyddb＠alpha.c2.org 17 Dec '03

17 Dec '03

On Fri, 22 Dec 1995 andr0id(a)midwest.net (Jason Rentz) wrote: >> >> > >The problem with the Interceptor is that I think it can only receive one >freqency at a time, and it is adjustable by a thumb wheel, not digitally. >This would tend to make changing frequencies at high rates VERY hard. :) >Also it has no frequancy readout, so this means that if you know what freq. >you should be at it is hard to tune in that freq. without searching a little. > Dr0id > > >( Computer Consulting & Management ) >(P.O. Box 421 Cambria, IL 62915-0421) > The demo of the Interceptor I saw seemed to show it jumping from 150 MHz to 450 MHz without any external adjustments, it locked on the strongest signal. Granted, it can only receive one frequency at a time, but there shouldn't be any significant delays when the phone hops a frequency. The Interceptor's frequency readout is a bargraph style LED. The Scout, from what I can see in Optoelectronics' ad doesn't have any frequency controls on it, it does have a digital frequency readout. As far as timing is concerned, the Scout might be less useful because I think it feeds the frequency into the scanner for reception. Most scanners take a significant amount of time to change frequencies. Merry Christmas Floyd D. Barber floyddb(a)alpha.c2.org Key fingerprint: 8A 98 1F 6B 70 7A FE 24 35 D4 48 CF 9D F6 B0 91

1 0

(fwd) Java implementation of secure login protocol
by Adam Shostack 17 Dec '03

17 Dec '03

Look, Ma! Java code! Real cyph3rpunks, of course, flame each other anonymously. (Incidentally, I got tired of Alice making it to my noise box, and the following seems to work well. Deleting the leading ^ characters would cause all responses to go into the junk box; perhaps a good idea. This is, for those of you who don't recognize it, procmail code. My mail filter of choice for hacking in.) :0B: * ^Alice de 'nonymous * ^P.S. This post is in the public domain. | formail -a "Status: O" >> cjunk > From: greg(a)qualcomm.com (Greg Noel) > Newsgroups: comp.lang.java,sci.crypt > Subject: Java implementation of secure login protocol > Date: 19 Dec 1995 23:12:52 -0800 > Organization: QUALCOMM, Incorporated; San Diego, CA, USA > Lines: 64 > Message-ID: <4b8d1k$6o9(a)qualcomm.com> > NNTP-Posting-Host: guru.qualcomm.com > > Please note that this article is cross-posted both to comp.lang.java and > sci.crypt. If you follow up, please trim the newsgroups appropriately. > > Since a number of people expressed interest, I'm releasing an initial > implementation of a secure login protocol in Java. This is still very > much a work in progress (it's not really even of alpha quality), but > the protocol itself is functional. > > It's intended that the classes in crypto.* and qualcomm.qbs.login.* > live on the client; any other classes needed would be downloaded over > the encrypted link. Hopefully, the client-resident classes will be > few in number and change rarely; they are just intended to bootstrap > up the connection. In the long run, the classes in crypto.* could be > provided by the vendor of the Java VM. > > The distribution consists of two files: > ftp://ftp.qualcomm.com/pub/gnoel/java.login.tar.gz > ftp://ftp.qualcomm.com/pub/gnoel/java.no-export.tar.gz > The first file contains the logic to execute the protocol and launch > the splash screen (see below); it also contains the base classes from > crypto.* but no cryptographic functions. The second file contains the > base classes and the actual implementations of a few cryptographic > functions to demonstrate how the base classes can be used. > > For sci.crypt, I've tried to capture the essence of what cryptographic > functions can do in the base classes, without being specific to any > particular protocol. I'm not completely happy with it, and would welcome > any comments people might have on what might be missing. It's as minimal > as I could make it and still provide a basis for whatever protocols need > to be implemented. > > My motivation here is that Sun and Netscape are talking about defining > a standard way of incorporating cryptographic functions in Java; it would > be nice if the specification were usable for a lot more than the security > protocols that come with Netscape. (I wouldn't object to having access > to SSL from Java---in fact, I'd really like it---but I'd also like access > to MD5 and the like.) > > This implementation of the secure login protocol uses short text strings > to identify the packets being exchanged; that's for convenience while > debugging---in a production implementation, it would be done differently. > Other than that, I'd appreciate any suggestions as to how to improve the > implementation. (A MAC digest prefixed to the packets is something I'm > considering, for example.) > > For comp.lang.java, the splash screen is loaded over the secure connection > but attempts to instantiate a member of the class cause a NoSuchMethodError > to be thrown. The class itself seems to be defined correctly, and it should > be no different from how an applet would be loaded and instantiated, but it > still fails. If anyone can tell me what is going wrong and what I can to > to fix it, the pizza and beer will be on me. (This has been a showstopper > for four days now and I'm getting very frustrated by it.) > > The class design tries to minimize the number of classes that must be > present in the bootstrap set; this led to a somewhat, ah, baroque set of > functionality. If anyone has suggestions on how this could be done better, > I'd be pleased to hear about it. > > If anyone has any questions about this, don't hesitate to drop me a line > or post something in one of the newsgroups. I'm going home for some sleep > now, but I'll be banging my head against it again in the morning. > > -- > -- Greg Noel, UNIX Guru greg(a)qualcomm.com or greg(a)noel.cts.com

1 0

Re:
by stevenw＠best.com 17 Dec '03

17 Dec '03

>On Fri, 22 Dec 1995 andr0id(a)midwest.net (Jason Rentz) wrote: >> >>The problem with the Interceptor is that I think it can only receive one >>freqency at a time, and it is adjustable by a thumb wheel, not digitally. >>This would tend to make changing frequencies at high rates VERY hard. :) >>Also it has no frequancy readout, so this means that if you know what freq. >>you should be at it is hard to tune in that freq. without searching a >>little. >> Dr0id > >The demo of the Interceptor I saw seemed to show it jumping from 150 MHz >to 450 >MHz without any external adjustments, it locked on the strongest signal. >Granted, it can only receive one frequency at a time, but there shouldn't >be any >significant delays when the phone hops a frequency. The Interceptor's >frequency readout is a bargraph style LED. The Scout, from what I can >see in Optoelectronics' ad doesn't have any frequency controls on it, it does >have a digital frequency readout. As far as timing is concerned, the Scout >might be less useful because I think it feeds the frequency into the >scanner for >reception. Most scanners take a significant amount of time to change >frequencies. I used to work for a company that made frequency-hopping military radios. It's a catch-me-if-you-can game, a bit like the amusement arcade toy where stuffed rats pop up through holes and you try to whack them with rubber hammers. You can sure *see* where the next one is, but you can't get there fast enough to make contact. If you knew the pseudo-random pattern, you could anticipate and be there every time. Thus in a frequency-hopping radio you can push the retuning (read RF phase-locked loop) technology to its limit and build transmitters and receivers around them. These typically hop in the order of 100 times a second. The adversary has to find the uncorrelated signal very quickly indeed *and* have PLL technology at least as good as yours to recover anything from it. Finding the signal generally means listening to all frequencies at once, requiring huge amounts of hardware parallelism and/or realtime computing power. Once you throw ten or so radios onto the same band, it's no longer any use looking for the strongest signal, making that approach useless. The primary reason for FH is not to hide information, however. Encryption can be used for that. It's to prevent the enemy from hiding the information from the intended recipient through jamming. Radio jammers work by simply drowning out all other traffic so that the receivers either clip and distort everything or have to attentuate the input signal so far that the interesting stuff is undetectable. Like trying to have an intellectual conversation at a bad rock concert. By employing FH you require the enemy to have enormous and impractical jamming capacity. There are FH radars too. ------------------------------------------------------------------------- Steven Weller | "The Internet, of course, is more | than just a place to find pictures | of people having sex with dogs." stevenw(a)best.com | -- Time Magazine, 3 July 1995

3 2

Re: CFS and Linux (fwd)
by Jim Choate 17 Dec '03

17 Dec '03

Forwarded message: > Subject: Re: CFS and Linux > Date: Sat, 23 Dec 1995 11:15:40 -0500 > From: "Perry E. Metzger" <perry(a)piermont.com> > > Alice B. Cohen writes: > anonymous-remailer(a)shell.portal.com writes: > > > 1: please make it install 'out-of-the-box' on Linux. > > > > AT&T's refusal to support CFS and other so-called "secure" software > > under Linux is typical and to be expected. > > God, you are an obnoxious prick. > Ditto. > First of all, this is Matt Blaze's pet project, not a product of > AT&T. It is given away for free and you should be happy to get it at > all -- no one is obligated to give you a gift. Have you mailed him a > Linux machine to do his testing on? Why do you assume he even has one? > As it happens, he doesn't, and probably doesn't want to go through the > hassle of paying for a computer and putting Linux on it. > > Be happy he's given you anything at all. > > Perry > If you are going to do it, do it right the first time. Second, I really doubt Blaze has a problem obtaining access to computing power and a $25 CD should be within his budget. Merry Christmas.

5 4

Polish telco policy change
by nobody＠REPLAY.COM 17 Dec '03

17 Dec '03

Pardons requested from those who rightly try to keep Cypherpunks focused. If any of you can think of ways to get this message out and about, you'd be doing a Good Thing: without bandwidth, privacy means a lot less. >------- Forwarded Message------- >Date: Tue, 19 Dec 1995 15:55:49 +0100 (MET) >From: Marta Dubrzynska <martad(a)pap.waw.pl> >To: Marjan Kokot <marjan(a)kud-fp.si> >Subject: Polish internet > >Dear Netpersonality, > >This is a request for help on behalf of the Polish internet. We >have one single internet provider in Poland: NASK. NASK has >bacause of an agreement with the Polish Telecom a >monopoly on lines connecting Poland with the rest of the world. >University's schools and commercial internet providers have to >get their acces from NASK. >Prizes of internet are high. A complete account with SLIP etc. >costs around 60 $ a month. Telephone costs are 3.7 $ per hour. If you >take into account that wages of around 350 $ per month are >considdered normal it is clear why internet is not used by so many people >in Poland. >And now NASK announced that too many people are using the >internet and that they need more money to keep the lines open. >They decided that from January they would raise the prizes, >and that they would calculate costs per bytes sent or recieved. >Yes that's right, we have to pay for letters you send us and we >have to pay for WWW pages you download from us. This will mean >the end of most internet activity in Poland. >If you want to know the details you can find them at: >http://galaxy.uci.agh.edu.pl/~szymon/protest-eng.html >http://www.put.poznan.pl/hypertext/isoc-pl/battle.html >protest(a)uci.agh.edu.pl > >That's why we Marta Dubrzynska, Webmaster of the Centre for >Contemporary Art in Warsaw, (http://sunsite.icm.edu.pl/culture/csw/) and >Michiel van der Haagen, Net user (http://www.atm.com.pl/COM/michiel/) ask >your help. >Can you make it clear to our Government and NASK that this policy is >disasterous for Polish culture, economy and education? Please check out >these WWW adresses and react.

1 0

Re: CFS and Linux
by Perry E. Metzger 17 Dec '03

17 Dec '03

Fred Cohen writes to me in private: > > Alice B. Cohen writes: > > If you mean to imply that I am Alice, that constitutes slander, and I > will sue. I'd love to see you try. Please, sue me immediately. Since you agree in public with Alice practically all the time, the damages would be fascinating to assess. "Your honor, my client, who has no reputation in the group we are discussing to speak of, feels that by being publically conflated with this anonymous personage who's opinions he univerasally agrees with that his reputation has been damaged, since, well, er, we aren't sure why, but it has. I mean, people might ascribe opinions to him that he claims to hold! Obviously that must be damaging!" What would the monetary damages be, Fred? I mean, there are some people here who would gain a bit of added respect for you since being Alice would imply that you knew how to use anonymous remailers, so there would be some evidence that you could do *something*, which many people here had in doubt up until now. I suspect you actually gain reputation that way, so perhaps I should sue you for unjust enrichment. (*) Perry (* Not close captioned for the sarcasm impaired.)

1 0

Announcing SecureDrive 1.4a
by Edgar Swank 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- This is to announce the availability of Version 1.4a of SecureDrive. SecureDrive Version 1.4a replaces version 1.4, 1.3d, and previous versions. Release 1.4a is a maintenance release of 1.4. No new function is added. Only module SDCOMMON.C has a non-cosmetic change, which affects executables LOGIN.EXE and CRYPTDSK.EXE. For that reason, all other executables still self-identify as release 1.4. They are in fact the exact same EXE & COM files as release 1.4. 1.4a fixes a problem decrypting or activating a diskette or disk partition encrypted with both a passphrase and a keyfile. There are also some minor changes in SECDRV.DOC. In the USA, SecureDrive 1.4a is not available at Colorado Catacombs BBS - 303-772-1062 (up to 28,800 bps, 8n1) - log in with your own name or alias. Download SECDR14A.ZIP from the [F]ile menu. see ftp://ftp.csn.net/mpj/README for the ??????? in ftp://ftp.csn.net/mpj/I_will_not_export/crypto_???????/disk/secdr14a.zip See ftp://miyako.dorm.duke.edu/pub/GETTING_ACCESS for access to ftp://miyako.dorm.duke.edu/mpj/crypto/link/mpj/disk/secdr14a.zip These are all controlled-access sites available to USA citizens and residents only. Thanks to the cooperation of Steve Crompton of the U.K., who worked with me closely, I am able to also announce availability on an offshore site, ftp://utopia.hacktic.nl/pub/replay/pub/incoming/SECDR14A.ZIP If you perchance don't find it there try directories /pub/replay/pub/crypto/CRYPTOapps /pub/replay/pub/disk which currently contains previous versions of SecureDrive. But as I write, SECDR14A.ZIP has been left in the incoming directory for several days. Steve also uploaded 1.4a to ftp.ox.ac.uk/incoming But it has been removed from there and has (so far) not reappeared elsewhere. But previous versions are in directory pub/crypto/misc so it might be worth checking there from time to time. In case anyone in the U.S. Justice Dept. is reading this, Steve and I were very careful to do this release without violating US export restrictions. The only things I "exported" to Steve were "diffs" for source changes from 1.4 to 1.4a, which themselves don't contain any code capable of encryption or decryption. Steve combined those with source for 1.4, which "leaked" from the US sites where I released it months ago. Steve compiled the new source code, and sent the new EXE files to me. I compared the new executables to ones I compiled myself and verified they match, bit for bit. I then sent back to Steve detached signature files for the executables. Steve then put together SECDR14A.ZIP and sent that to me for final inspection. I then compared all files against my "master" files here and verified that they matched. I then shipped the SECDR14A.ZIP that Steve sent me to the USA sites. So the USA release matches bit for bit the offshore release. Here are the contents of SECDR14A.ZIP Length Method Size Ratio Date Time CRC-32 Attr Name ------ ------ ----- ----- ---- ---- -------- ---- ---- 18321 DeflatN 6923 63% 06-14-93 22:27 0767480b --w- COPYING 2022 DeflatN 789 61% 08-06-95 00:00 dd3e9e64 --w- COPYSECT.C 12542 DeflatN 7674 39% 08-06-95 00:00 c089888f --w- COPYSECT.EXE 152 Stored 152 0% 08-06-95 00:00 17b02bc2 --w- COPYSECT.SIG 19664 DeflatN 4241 79% 11-19-93 21:42 22c2502c --w- CRYPT2.ASM 19625 DeflatN 4618 77% 11-10-95 16:11 3a6b64fe --w- CRYPTDSK.C 41898 DeflatN 19879 53% 11-14-95 18:59 26bc0200 --w- CRYPTDSK.EXE 4353 DeflatN 1723 61% 08-06-95 00:00 b4e99e6a --w- FPART.C 15450 DeflatN 9794 37% 08-06-95 00:00 44c4a0e7 --w- FPART.EXE 152 Stored 152 0% 08-06-95 00:00 0b345a16 --w- FPART.SIG 5278 DeflatN 3468 35% 11-14-95 20:52 af2f141c --w- KEY.ASC 18450 DeflatN 4541 76% 11-10-95 16:13 c5ad8fa4 --w- LOGIN.C 43558 DeflatN 20297 54% 11-14-95 18:59 cfd0bd3b --w- LOGIN.EXE 278 DeflatN 250 11% 12-06-95 20:33 6c13428c --w- FILE_ID.DIZ 1554 DeflatN 568 64% 08-06-95 00:00 3589f489 --w- MAKEFILE 11557 DeflatN 3315 72% 05-09-93 19:38 e71f3eea --w- MD5.C 3407 DeflatN 1104 68% 05-11-93 12:49 f1f58517 --w- MD5.H 1355 DeflatN 629 54% 01-21-94 08:44 db63ade4 --w- RLDBIOS.ASM 14819 DeflatN 4087 73% 11-14-95 18:56 592274c6 --w- SDCOMMON.C 52551 DeflatN 19113 64% 12-06-95 15:33 cf5e3ded --w- SECDRV.DOC 3656 DeflatN 1098 70% 08-06-95 00:00 6ed75bcc --w- SECDRV.H 32595 DeflatN 8906 73% 08-06-95 00:00 1c7d2225 --w- SECTSR.ASM 2000 DeflatN 1326 34% 08-06-95 00:00 ba1568d1 --w- SECTSR.COM 152 Stored 152 0% 08-06-95 00:00 3817512c --w- SECTSR.SIG 11519 DeflatN 2864 76% 08-06-95 00:00 060d33e8 --w- SETENV.ASM 1254 DeflatN 541 57% 05-09-93 19:39 182978aa --w- USUALS.H 152 Stored 152 0% 12-06-95 17:05 2d1c5fc9 --w- CRYPTDSK.SIG 152 Stored 152 0% 12-06-95 17:10 8dae8ad5 --w- LOGIN.SIG ------ ------ --- ------- 338466 128508 63% 28 Also note that the ZIP file contains PGP detached signatures (*.SIG) for the executable files. Finally here is my public key, also available on many public keyservers; note who has signed it. Also please note my present Email address. Edgar Swank <edgar(a)Garg.Campbell.CA.US> (Only Garg ID is now valid) Type bits/keyID Date User ID pub 1024/DA87C0C7 1992/10/17 Edgar Swank <edgar(a)Garg.Campbell.CA.US> sig 32DD98D9 Vesselin V. Bontchev <bontchev(a)complex.is> sig 0F59323D Albert Yee <sa3189049(a)ntuvax.ntu.ac.sg> sig DA87C0C7 Edgar Swank <edgar(a)Garg.Campbell.CA.US> Edgar W. Swank <edgar(a)spectrx.sbay.org> sig 91E71221 Cruz <cruz(a)ccxbbs.uunet.ve> sig DA87C0C7 Edgar Swank <edgar(a)Garg.Campbell.CA.US> sig C0595F91 Ian H. Chan <ianchan(a)iti.gov.sg> sig 61130A1B Arnold L. Cornez, J.D. <arniec(a)dnai.com> sig 18239E91 Robert C.Casas <73763.20(a)compuserve.com> sig 4AAF00E5 Dave Del Torto <ddt(a)lsd.com> sig 08B707C5 Anton Sherwood <dasher(a)netcom.com> sig 32DD98D9 Vesselin V. Bontchev <bontchev(a)complex.is> sig 34D74DC1 Peter Simons <simons(a)peti.rhein.de> Edgar W. Swank <edgar(a)spectrx.saigon.com> sig 08B707C5 Anton Sherwood <dasher(a)netcom.com> sig 32DD98D9 Vesselin V. Bontchev <bontchev(a)complex.is> sig FF67F70B Philip R. Zimmermann <prz(a)sage.cgd.ucar.edu> - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAirfypkAAAEEAKe2jziPeFw6hY19clR2GtQ4gtGCSSVOTgPKEJzHfuC74Scf 9PEuu1kebLhHk43A9wo1vr52o4jpH/P/tnFmRtBQOMzLUzAt5rMucswtSVviMQS2 hBuc9yGJKWHVcyfA79EARKEYTdhx+2qKI+hFJcPE+rmD8wVoF94nNf3ah8DHAAUR tClFZGdhciBTd2FuayAgIDxlZGdhckBHYXJnLkNhbXBiZWxsLkNBLlVTPokAlQMF EDBmZEE2VpfGMt2Y2QEBEsID/0vobHvtD65LmaHQZzPd1fuZzxsKFXG5/dCwx60Q k624Yc7P1m1q+LY8KFuLtvSe1Ltn1dOpQ+eKOqdqh7z6BpywheHSwUPkA80QS9JI PFwj4FBBw5imvPihTG56TRfpDQn1kN2Slaurx3SADtbohOZXuzT+uagk9OWl0/NQ S/ubiQCVAwUQL5YBoVPK4mAPWTI9AQHFAQQAtjRStFaaWND/0ju+ciwcCvvHyQg8 /EEXYekopHkDhHcnD7oSqQhvk/4P4CEaDMKC2U/BQVdmhoXjTH9LpdlxqLuxIkDD 05NBAKJDiWaDcZDOXstHDsQB4X0R0SYn+l4fe0/Dhp+b7tLr0RTYr0A7X8bpi/w/ X68V3EjBph556MeJAJUDBRAvkjv43ic1/dqHwMcBAQnMA/9ORYVRk8WDrEY147hB FrZ3TYYF9XwqRCq7R9pI+75zS42R2CqoBSYSirruE9EcWB8HqDOc8DA9E2lJTGXn lByU6wp0ujAAn/VDEsecHXDaqbRi/y7BKybnRl3xH4grUsjLVnIQLih4BNBsYGnN co8ei8AekUd9jKN/bldazt53C7QnRWRnYXIgVy4gU3dhbmsgPGVkZ2FyQHNwZWN0 cnguc2JheS5vcmc+iQCVAwUQMIDsCDSU0PSR5xIhAQGiBgP8CNKY+MTVoLjUhaxF /FhQJHJe5MB2C3UoNuGGRNMzZLgo8JKtoe4c2cjXWg9GKHKFboIeibKuEdnfuBXF wqM8YlQhzlKRZf4FebO4LHg8y2rd2s43irIlv6ofQ9VdTdgYOumFGSCNb3SWi1Ei 1J7TjneNzj93sq+ecf2RblfDWC+JAJUCBRAtmPSp3ic1/dqHwMcBAWtDA/455Uev GU3OEL5LF+23MhQLeD5UAu4zqC/xv5zLGXS2WTCLof0byqY+H2evamlBlHmMdSG5 t+x6T9AaLzxTA5+5E92H5kOX+tTiQxxe91gZP1yU4uPNeZwszvL2/wXiYUuw228U 3apYuyqd7qFQjsQWfZ5r/y6N2bt6g2Wru3wLK4kAlQMFEC9NxzXpGeQvwFlfkQEB zeED+wfXXvD9aTSTh0l/RCJoGmDWzVqiKmXVCDxuY4S4q6/uN+zEchTVvkuB7acD W1iBa4s57yuI3Anl8U6CIE7Hxl9lYymxnPN0Synddn7rOMh7RjH68dzAM2ssA0eu E7nS0v2+dTdWfeKzOnAYRYf8Xglxy/8m4P2kcimVEatM4eQOiQCVAwUQLspTDYYo qqhhEwobAQEbuQQA1d1ZQbCecS1buYt3TadijMDvn2oMdpXHdC0zlhgHxsNXuJmH sX79dieg+P2HMXgdrSctwhI9cMcEeG2rsKxxgmfwN60nvUIwB7xl3/5b+86oKZSo 5FoxT8vW2qe+k5ZQ2ezA6TNE7M6Y2nD4qrgv6ioEW6ok8NdBhgQUo6y8H0uJAJUC BRAuJJU/XyTewRgjnpEBAblOBACfD1a1z4Z0ZJxnjyG8xZkAGdSIBdOHD5Orv0d0 +74jJI2LtpF+RJ6mmf1APq/Y5LwQtq2CRNK4a3gKkwTqEscHjp9OJN2hcx3D7PT3 aY66pUXapUq2zCcVqvkXLiPRcr/iUTHZ3b/UilpND6xuJwYf0KoKhY4oDLWPYvL0 l/tmB4kAlQIFEC3V00GhwThfSq8A5QEBB2ED+QHa9NcIiNka07D9sLqA5Mecw8FV NB5cchncFnjFhF0x90qzE3eBN7M4jxCLFCgfOG80YHTZ8HkR0Hz5SXD2SfTwBHZv 6ZPCSB422XK281nnYTtSlYRW3OfGUZ6LBExs4UhoYokWwZcVJHDcXz1mqhSeh5G9 GAvSQkhA5kIsXrZliQCUAgUQLaj9LxgzoWUItwfFAQEdywP2LSjZ3tDauwb+JFHB qnEYpBsc/GBBcIHowtU0MRrdz+meDyvY8D1w55FzDHbFj9fE25mjuUdc2n+PnHBi Giir7JMEkgvwNmpb31BPz5zTm/DszVQISnLs1PV7GQzOhVH9jeMpshrhfW1fVmt2 aijPFbRPcPAJwJnt1Hbp5leXHYkAlQIFEC2bD642VpfGMt2Y2QEBQsoD/jCp0yfY YICkCr7mQlP6ImYu9V41mPQlWNaykYNx37VyMIr1dZVMBNW1EB9ZsO6SgnbA3M27 PuBupUcdytXue9xC3cpSzFZHJqFESSVzvk+1cGbQ8qmvlM1MzYn8qqXbwZdBDIv4 8drBMNBUTzJsI+P5ZSArmp3Wj/ZA/GdvgQCZiQCVAgUQLZsasA9HL1s0103BAQGE sAP/e9agO7iazPhgDwFyd+6i8jQCkMvl6RK7jjsHJeAhyo1F7igO0Z2+upe8mGnK 6Pm3u9UMa3OBATSNTwfq745ymPWcGU5cvfoMBJJom4sSsHI0LOpNoZXJrlYbGYra b6kpLpRUheK0Xa0bGsq7492neuS/eg8dNZWAVPl4ZG98kgq0KUVkZ2FyIFcuIFN3 YW5rIDxlZGdhckBzcGVjdHJ4LnNhaWdvbi5jb20+iQCVAgUQLAAAujTiKn8yRb9d AQGY1AP/SNRWpPQsyhW/DtnPYVfJat0GfptGXIbF6pBaGKANdGKlnzbj98dsDa+R sBzMRrLDxmnBFWaFY2zHFaGNgUiL3YpglsA/9chuv6sS5MiE8oooqG64YtRaF9eE IWW4eOzcIDplDCdPiOe7U2UKRydYtsviS2q5vbMvCscI9R7fUvWJAJQCBRAr1jnT GDOhZQi3B8UBAc+sA/MFt/qVDLPBtTB3FrLMsOiHcfKCe6cuiiL7LPOIRVByE6BK 3ewt7YjXTwMvFOCn7bqUlhMBkH4aDwcbIH43PrbrcPReVVRdCL3/sJJHJ3xuFgV6 4U/AXMc9ZmXIsMAiy5oR8GyanYMEuB9++FQKqKJZiY/2hr6s4D7kgdL7E3y0iQCV AgUQK2PmLDZWl8Yy3ZjZAQEMRgP/aIwyaXrl4Vo1as0/tptiHxBbf4yePKXkI2kC MaTF6OYibidkqpQc3kO4bOkkOey1HBvPp1pcrXldygzWbyC6G7pTMjAez36FsoTq KdMLPgLSYTnk9Ka8X96ON7GcbOyIWm4WeM3+xGtIdznt+U4hRYEJkPweLPPdpgHG a/AnzreJAJUCBRArERcc4nXeDv9n9wsBAbJiA/9qly/1XYxscWBTSGXQPgwuoaMF F5R8OujFAKyCxNv/SevVb3KW0Eypg+APtOEsB/avEg81sbIPtVQDbstPBBNLqfaZ u2Qc68ZBXDsnYbBMDrfX0Z/RCd7QzWHtUlaMVfRXOO6H+eTpu3Eza5MtIXadSwNd 7n/03ld56wWGttc2sw== =n5hN - -----END PGP PUBLIC KEY BLOCK----- -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMNszct4nNf3ah8DHAQHBGQQAhbb0ZCJ3iiB096HxJac33XFTxG/GwNB4 4nWN5/I2s8Cve/USUGVC9YIHKV7NHkHn0Pybo727w46am6DMLoQTdnPzR2O+C+TY mozxnwDYfznzWCzjqadHOsPRK9/ix8aB2ThfGsNaAvOgVjvnDg/uG8ztLwW/G1Hv L/zVBh8nIs0= =YArx -----END PGP SIGNATURE----- -- edgar(a)Garg.Campbell.CA.US (Edgar Swank) The Land of Garg BBS -- +1 408 378-5108

1 0

Re: AWARD: CHRISTMAS NET SCROOGE - AT&T & NETSCAPE??
by anonymous-remailer＠shell.portal.com 17 Dec '03

17 Dec '03

On Fri, 22 Dec 1995, Perry E. Metzger wrote: > anonymous-remailer(a)shell.portal.com writes: > > Everyone should ask this question. AT&T can sign-on to a two-page ad, > > calling on Congress to balance the budget -- to cut off veterans, and > > cut-off women with dependent children just before Christmas. It can > > sign on to this, but it can't bother to even offer a scholarship to > > the students who helped make its fortunes. It would rather leave the > > impression that it freeloads off of other's efforts. > > God, you are annoying Fred, ER, I meant, "Alice". My dearest Perry. I am not Fred. I am not he. He is not me. Got it?? We aren't even in the same category or the same country. Fred's an American, and I am not. Scary, isn't it?? A non-American ... Oh ... and a Happy Ho Ho to ya, Perry. My own best wishes. (just in case you didn't get my email, which wished the same, I mean). And _none_ of this changes the fact that AT&T and Netscape are my personal nominees for the "Christmas Net Scrooge" award. Anyone willing to second, that?? Alice de 'nonymous ... <an455120(a)anon.penet.fi> ...just another one of those... P.S. This post is in the public domain. C. S. U. M. O. C. L. U. N. E.

1 0

Re: CFS and Linux
by Perry E. Metzger 17 Dec '03

17 Dec '03

Fred Cohen writes: > The dollar value would be $1 plus a public apology plus all costs of the > suit plus my time to right the wrong (at my usual fee of course). Of > course the fact that you have decided to make this posting in public > justifies my extensive efforts to clear my reputation which, unless you > apologize immediately will be surprisingly enjoyable for me. Go and sue, Fred. Its what I have lawyers for. If you can even find an attorney willing to take your "case", mine will likely remind yours that lawyers can now be punished by the court in many jurisdictions for knowingly aiding in bringing frivolous suits. If you are seeking $1 in damages the court is especially likely to consider the whole thing a waste of time. I think you will find that I'm very, very hard to intimidate. Don't bother "giving me a second chance" or any such stuff. Either find a lawyer stupid enough to risk his license by taking this case and let me know you are suing me by sending over a process server, or quit bothering me. > Let's see. I guess I would start by having the police confiscate the > toad.com computers becfause thay are part of a criminal conspiracy to > daamage my reputation. Criminal because of the recent changes in the > law that prohibit you from sending me information I don't want to get. I think you will find that John Gilmore is even more difficult to intimidate than I am. Perry

1 0