- cypherpunks-legacy - lists.cpunks.org

SSLeay 0.5.1
by Eric Young 17 Dec '03

17 Dec '03

SSLeay 0.5.1 is now available. It should be quite stable and has documentation for the lower level cryptographic routines. It is incompatible with the previous version but has no global variables of consequence so it should be a much nicer starting point for threaded libraries. The library should have no memory leaks and the general cryptographic functionality has been filled out more. Tim Hudson <tjh(a)mincom.oz.au> will be updating the applications available on ftp.psy.uq.oz.au in the next few days. I leave for an 11 week holiday today so please address any problems and questions to the ssl-users(a)mincom.oz.au mailing list (if it is of general interest) or to ssleay(a)mincom.oz.au which goes to both myself and Tim Hudson (who will be fixing any bugs while I'm away). Anouncing software and then leaving for 3 months would probably not normally be considered a good practice but 0.5.0 has been tested for the last week or so and I have faith in Tim Hudson's ability to fix bugs after doing pre-alpha testing for the last 6 months :-) As per usual, the primary ftp site is ftp://ftp.psy.uq.oz.au/pub/Crypto/SSL http://www.psy.uq.oz.au/~ftp/Crypto Documentation on the demo application is sparse but I hope Tim Hudson will be able to fill in the gaps while I'm away :-) eric <eay(a)mincom.oz.au> -- SSLeay v 0.5.1 21/12/955 Copyright (c) 1995, Eric Young All rights reserved. This directory contains Eric Young's (eay(a)mincom.oz.au) implementation of SSL and supporting libraries. The current version of this library is available from ftp://ftp.psy.uq.oz.au/pub/Crypto/SSL/SSLeay-x.xx.tar.gz There are patches to a number of internet applications which can be found in ftp://ftp.psy.uq.oz.au/pub/Crypto/SSLapps/ A Web page written by Tim Hudson <tjh(a)mincom.oz.au> can be found at http://www.psy.uq.oz.au/~ftp/Crypto This Library and programs are FREE for commercial and non-commercial usage. The only restriction is that I must be attributed with the development of this code. See the COPYRIGHT file for more details. Donations would still be accepted :-). The package includes libssl.a: My implementation of Netscapes SSL v 2 protocol. This library implements the SSL protocol. libcrypto.a: General encryption and X509 stuff needed by SSL but not actual logically part of it. It include routines for the following: libdes - My libdes DES encryption package which has been floating around the net for a few years. It includes 15 'modes/variations' of DES (1, 2 and 3 key versions of ecb, cbc, cfb and ofb; pcbc and a more general form of cfb and ofb) a fast crypt(3), and routines to read passwords from the keyboard. RC4 encryption, IDEA encryption - 4 different modes, ecb, cbc, cfb and ofb. MD5 and MD2 message digest algorithms, SHA (SHA-0) and SHA-1 message digest algorithms, RSA encryption/decryption/key generation. There is no limit on the number of bits. Diffie-Hellman key-exchange/key generation. There is no limit on the number of bits. X509 encoding/decoding into/from binary ASN1 and a PEM based ascii-binary encoding which supports encryption with a private key. Programs in this package include enc - a general encryption program that can encrypt/decrypt using one of 17 different cipher/mode combinations. The input/output can also be converted to/from base64 ascii encoding. dgst - a generate message digesting program that will generate message digests for any of md2, md5, sha (sha-0) or sha-1. asn1parse - parse and display the structure of an asn1 encoded binary file. rsa - Manipulate RSA private keys. dh - Manipulate Diffie-Hellman parameter files. crl - Manipulate certificate revocation lists. x509 - Manipulate x509 certificates, self-sign certificates. req - Manipulate PKCS#10 certificate requests and also generate certificate requests. genrsa - Generates an arbitrary sized RSA private key. gendh - Generates a set of Diffie-Hellman parameters, the prime will be a strong prime. ca - Create certificates from PKCS#10 certificate requests. This program also maintains a database of certificates issued. verify - Check x509 certificate signatures. speed - Benchmark SSLeay's ciphers. s_server - A test SSL server. s_client - A test SSL client. s_time - Benchmark SSL performance of SSL server programs. Documents included are A Postscript and html reference manual (written by Tim Hudson tjh(a)mincom.oz.au) A list of text protocol references I used. A initial version of the library manual. To install this package, read the INSTALL file. This library has been compiled and tested on Solaris 2.[34] (sparc and x86), SunOS 4.1.3, DGUX, OSF1 Alpha, HPUX 9, AIX 3.5(?), IRIX 5.[23], LINUX, NeXT (intel). For people in the USA, it is possible to compile SSLeay to use RSA Inc.'s public key library, RSAref. From my understanding, it is claimed by RSA inc. to be illegal to use my public key routines inside the USA. Read doc/RSAref.doc on how to build with RSAref. Read the documentation in the doc directory. It is quite rough, but it lists the functions, you will probably have to look at the code to work out how to used them. I will be working on documentation. Look at the example programs. There should be a SSL reference manual which is being put together by Tim Hudson (tjh(a)mincom.oz.au) in the same location as this distribution. This contains a lot more information that is very useful. For a description of X509 Certificates, their use, and certification, read rfc1421, rfc1422, rfc1423 and rfc1424. ssl/README also goes over the mechanism. We have setup some mailing lists for use by people that are interested in helping develop this code and/or ask questions. ssl-bugs(a)mincom.oz.au ssl-users(a)mincom.oz.au ssl-users-request(a)mincom.oz.au This library is reasonable stable now. Version 0.5 has had extensive rewriting since version 0.4. The purify package has been used extensively and I believe most if not all memory leaks have been removed. There are no writable global variable so a multi-threaded/DLL version of the library should be quite simple to write. Look at TODO for a list of thinks I know I still need to do. eric (December 1995) Eric Young (eay(a)mincom.oz.au) 86 Taunton St. Annerley 4103. Australia.

1 0

Cypherpunks resumes?
by nobody＠REPLAY.COM 17 Dec '03

17 Dec '03

Is there any chance of seeing a Cypherpunks 'Rogues Gallery' of sorts in the archives anytime soon? It would be nice to see a face connected to the postings here. Some of us don't get the chance of getting out west for the parties, The only other thing I know about Tim May besides being one of the Fathers of the Cypherpunks is that he was a naked hippie in a hot tub at some party that Robert Hettinga was at some weeks ago, That doesn't paint a good picture for me. Thanks, A.E.N.

1 0

Re: What ever happened to... Cray Comp/NSA co-development
by tcmay＠got.net 17 Dec '03

17 Dec '03

Anitro wrote: >O.K. Just a factor of 16 increase over the CM architecture right? Not knowing >the computational capabilities of the individual processors, it might be >difficult to say what the machine is capable of. Wouldn't that have some >bearing? Not in cracking "truly large" problems by brute force. Even if each of the million processors is capable of 100 MIPS (which is unlikely, given the PIM approach and the fine-granularity, few-bit-or-less word size, etc.), this is only 10^8 MIPS. For problems that (for instance) 10^75 machines would have to spend 10^10 years on, not even a drop in an ocean. The point is that no existing machines are going to make a dent in these calculations, though algorithmic cleverness _might_ make factoring much easier (personally, I doubt it). >> Second, there was work on a "processor-in-memory" architecture, in >> conjunction with a Bowie, Maryland spook-connected company. Perhaps this is >> what you are thinking of? > >I didn't mention a 'processor-in-memory' architecture and neither did the NYT >article. Don't know about any other company involvement, just CCC and NSA. I wrote my response before seeing the other response someone else (Thaddeus J. Beier) gave the name of the company. Thad's details match what I recall about this Bowie company. The archives should have articles on this, dating back about a year or so ago. As I recall, someone on the list knew people working at the Supercomputer Research outfit. >> Third, all avenues of continued funding having fallen through, Cray >> Computer (not Cray Research, of course) was shut down and assets >> liquidated. I haven't heard what's become of Seymour, though. (He is >> undoubtedly an asset, buy I doubt the Agency would have him liquidated.) > >You mean the avenues that are of PUBLIC record. The possibility could always >exist that the development continues 'in-house'. It wouldn't be the first time >that sort of move has been played. You, whoever you are, asked about the operational status of Cray Computer, and I answered. It entered Chapter Seven liquidation, parts of existing computers were sold for scrap or museum/curio objects, the GaAs fab was sold to another company, and the employees scattered. Claiming the NSA moved it "in-house" is implausible, at least in terms of these events. >> Huh? First, what evidence do you have for this claim? Second, who cares? >> Implementing Clipper in a Cray Computer machine--why bother? > >[Rant mode on] >Speculation Tim... I'm SPECULATING. Could, in theory... AND my kind of theory >probably has holes you could drive a FLEET of Mack trucks through. I have NO >evidence. I'm not sure WHO would care. I'M A PARANOID DILLUSIONAL PSYCHOPATH! >O.K. well maybe not that last part... but I'm asking the questions, remember? >I said I'm new here, so if your going to blow holes in my pet theories, then >do me the 'kindness' of using an accurate weapon... that's why I posted... I asked what evidence you have for this claim. Idle speculation, based on innumerate estimates of plausibility are helpful to no one. >> As to the claim that a million-processor machine could do this, you need to >> work out the math. (If a backdoor exists, or the LEAF has been gotten, a >> supercomputer is not needed....) > >Again... I claimed NOTHING! SPECULATED MUCH! Now it's your turn... Why would >YOU build a machine like this? What could POSSIBLY be it's capabilities? >Speculate with me for a moment... *_take a chance_*. On our list, and in the circles I am familiar with, "speculations" are not treated with more respect than are actual "claims" (whatever they are). If you speculate that "really, really fast computers" will make today's ciphers insecure, based on not even the simplest of calculations, expect to be either ignored or called to task. This is the way science works, by falsification of theories (and speculations). >> If you mean using supercomputers to brute force the general factoring of an >> RSA modulus, this is nonsense. While there may be math shortcuts we don't >> yet publically know about which make factoring easier than we currently >> think it is, a mere million or even a billion processors will not make a >> dent in the factoring of, say, a 700-digit modulus. See the tables in >> Schneier and elsewhere for some estimates of factoring efforts needed. > >Nonsense? Is that 700 decimal digits or 700 binary digits? I don't have the >tables that you refer to. Where may I find them? (LOL) A 2048-bit key, such as many of us use, uses a roughly 700-decimal-digit modulus. "Schneier," mentioned in my paragraph, is "Applied Cryptography." Page 284 of the 1st Ed. has a discussion of the work involved in factoring large moduli. Rivest has made some more detailed estimates. Given your rudeness and self-professed ignorance of even the basic math, I see no point in wasting any more of my time on your posts. --Tim May Views here are not the views of my Internet Service Provider or Government. ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^756839 | black markets, collapse of governments. "National borders are just speed bumps on the information superhighway."

2 1

Re: COMMUNITY CONNEXION PIONEERS PRIVATE ELECTRONIC COMMERCE
by Robert Heffren 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- On 19 Dec 95, sameer <sameer(a)c2.org> wrote; > COMMUNITY CONNEXION PIONEERS PRIVATE ELECTRONIC COMMERCE > Community ConneXion today announced a new service for its customers > which will make secure, private electronic commerce more accessible > to all merchants, from the small single-person business to large > corporations trying to sell goods and services over the > world-wide-web. There went the neighborhood. The Prez and the Coalition on one side and big biz on the other. AOL and their stings, all the motherfuckers spamming the piss out of everybody else and every place you turn, some swinging dick wants to put his goddamn hand in your pocket. Fuck it! Shut this sonfabitch down and take up doll-collecting. Who NEEDS this bullshit! Unsub this bastard AND gone; -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQB1AwUBMNlMrBMzypiVqpjNAQG/fAL9GS5NiWR/5mb+KbKwxp2wSB6MUliwJaEV uBb+a7F5s7PQ0lQEWfujPKIoaF/iCB0zRKN0yLWCuvNiQe3YWMnwn5WggPekDRPl 0b3u37WHmeCKyhamMixnyK4w7jjT2use =WaxG -----END PGP SIGNATURE-----

1 0

Re: Microsoft Flame[tm] [NOISE]
by RobL 17 Dec '03

17 Dec '03

At 06:32 AM 12/21/95 CST, Roy M. Silvernail wrote: >-----BEGIN PGP SIGNED MESSAGE----- > >There's a lot of finger waving going on over Microsoft's alleged >predatory practices. I just want to remind the pro-MS folks of >something. Microsoft has a documented track record of using >undocumented entry points in their OS and Windows products. These entry >points allow MS apps to do some things more efficiently than a [snip] > >While this isn't the grand-scale conspiracy some people seem to see, >IMHO it's still predatory. Perhaps the call to separate the OS and apps >divisions is a good idea. It would be interesting to see if Microsoft >could maintain its edge in applications when it had no sub rosa >advantage in OS access. IMHO, I see nothing wrong with predatory behavior.. then again, I hunt in the fall, so it must be a redneck thing.. MS and any of the other software companies are competing for domination in a narrow field.. MS just happens to be the only real choice for OS anymore.. well, for a standard, out of the box OS anyways. The fact that they have to leave in undisclosed hooks to get their own software to excell over others just points to the poor software they produce overall. I have to admit that I like, possibly admire, the way the Bill and crew have captured the market.. from a marketing standpoint, they did a first rate job of running with the ball until there was no pursuit.. Sure, from time to time, someone tries to throw a blocker in thier path, but they just overrun it and keep going.. Forget about the monopoly aspects for a second and look at MS as an American success story. It has all the classic elements: started small, with a crew of social misfits and eventually grew up. Just a few cents worth.. RobL ------------------|----------------------------------------------------------- Rob Lowry | PO Box 288 | Rockford Wa 99030 | ral(a)otc.mhs.compuserve.com robl(a)on-ramp.ior.com

1 0

brief review of MIT 12/15/95 "micro-commerce" talks
by james＠sparta.lcs.mit.edu 17 Dec '03

17 Dec '03

This is a quick summary of the Friday 12/15/95 talks at MIT on micro-commerce: Millicent --- Mark Manasse, Digital Equipment Corporation Brokers purchase "scrip" in large batches from vendors; users purchase scrip small batches from brokers; users give small scrip to vendors in each purchase transaction. "Scrip" is vendor-specific and its validity can be efficiently verified using hashing. No public-key crypto is required to carry out the protocols, because pairwise trust relationships between user and broker, and between broker and vendor, are established and these pairs share secrets. PayWord --- Ron Rivest, MIT Users are issued certificates by brokers, indicating that the broker will extend credit to the user. Users generate long hash-chains by repeatedly hashing a random seed value to obtain a hash-chain root. Then the user promises to a specific vendor that he will pay one cent per element of that hash-chain. This promise is made by the user signing (using PKC) the root of the hash chain. Each time the user wants to pay one cent to the vendor, she sends another element of the hash-chain, working backwards from the root, as in the S/Key system. The vendor redeems the whole chain (or whatever portion the user has spent) by sending the user's signed promise and the last spent element of the chain to the broker. MicroMint --- Adi Shamir A scheme for issuing coins that is much more like traditional physical coin systems in that forgery and cheating are possible, but only practical on a large scale, and are detectable and can be combatted. A "coin" in the MicroMint system is a set of 4 values that hash to the same value. Producing such 4-way-colliding values is much less expensive in bulk than individually. The mint produces coins in bulk and will redeem them into cash. To combat active forgers, the mint can embed secrets in the coins and reveal the secrets progressively so that vendors can detect forged coins cheaply. Lightweight Signatures for Revocation --- Silvio Micali, MIT A cost/performance analysis of the key revocation system for the U.S. Federal Goverment's Public Key Infrastructure. Taking a MITRE-designed plan as a starting point, the communications costs are analyzed. In the MITRE plan, the certification authorities issue revocation lists on a semi-weekly or daily basis, these lists being then stored in an untrusted and highly replicated database. When a public key is being checked, the receiver queries the database to determine the status of the public-key. In the talk, Silvio showed how lightweight signatures can be used to reduce the size (and therefore transmission cost) of the revocation lists. He also showed that transmission costs can be dramatically reduced by not sending large revocation lists in response to queries. Instead, the replicated database can store a timestamped key-status-report (signed by the certification authority) for every single key. This key-status-report is much smaller than the full revocation list. Overall, the PayWord scheme is probably the one to watch for actual use on the Internet. Millicent has an advantage of not using PKC, but PayWord may be simpler to implement and is being discussed in the WWW Consortiom and the IETF as a possible draft standard. It is also worth noting that PayWord operates essentially by combining a PKC-signature-based authentication (between user and broker) with a One-Time-Password (OTP) authentication scheme (as in the S/Key system). OTP has been getting standardized recently on the Internet and maybe that will help too.

1 0

FWD: Intuit and SSNs
by nobody＠REPLAY.COM 17 Dec '03

17 Dec '03

What does our man in Intuit have to say about this? > Date: 18 Dec 1995 19:10:07 -0800 > From: michael(a)piglet.amscons.com (Michael Bryan) > Subject: SSN Shown On Payments by Intuit's Banking Service > Organization: none > > Another user (Robert Mayo) discovered, and I confirmed, that Intuit's > online bill payment service sends your payees a printout containing > your social security number. > > This applies to any person who is using Quicken for Windows or > Microsoft Money for Windows to send payment requests electronically, > using Intuit's service. It specifically does -not- apply to using > Quicken with the Checkfree service, as the Checkfree service does not > supply anybody with your SSN. > > The details: > > When the Intuit service sends a payment to a merchant, it will do one > of three things. First, it will try to perform an EFT directly from > your account into the merchant's. Most merchant's are still not setup > for this, however. Second, if your payment is the only payment going > to a given merchant on a given day, then they will print a check, drawn > against your account, and mail it to the merchant. Both of these > methods are ok, and do not result in your merchant receiving your SSN. > > However, if there are multiple payments going to a single merchant on a > given day (i.e., more than one customer has requested a payment to the > given merchang), all of these payments are sent in a single envelope, > and a summary sheet is enclosed. This summary sheet will have a field > called "Control Number", which consists of your SSN, followed by two > other digits. This summary also lists your checking account number, in > addition to your name, account with the merchant, and the amount of > your payment. (In my opinion, only these last three fields are called > for. There is no need for the checking account number to be listed, > even though it -is- printed on your check as part of the MICR > encoding.) > > I have contacted Intuit regarding this matter, and they have been > decidedly less than helpful. I know at least three other people who > have called them, and we have all been told the same thing: > > 1) "Most of your merchants already have your SSN". Perhaps this is > true for some people, but it is not the case with me. > > 2) "The SSN is encrypted on the printout". Absolutely not true. It is > printed under the label "Control Number", and has two extra digits > appended, but this does not "encrypt" the number. Anybody who knows > what the field contains has instant knowledge of your SSN. > > Intuit is currently refusing to address this issue. Furthormore, when > I called in, they tried to tell me I was the only person who was > complaining. I immediately gave them the names of three other people > who had called in, one of whom I knew had talked to this particular > individual. So that little "divide-and-conquer" trick backfired. > > Also, when I said that I would be forced to go to the media if they > didn't address this issue, I was told that by doing so, I would be > responsible for broadcasting this information to those who might then > illegally use the information. I found this two-faced attitude > particularly annoying. On the one hand, they are claiming it's not a > problem, yet on the other they tried to keep me from going to the media > because it might give criminals information they could then exploit. > > Anyway, I've done all I can with talking to Intuit, so I am now > pursuing other avenues. My bank (Union Bank) was particularly > concerned that the SSN was being printed out and mailed with > potentially every payment, and vowed to look into it and work with > Intuit on my behalf to get this behaviour stopped. Also, I and a few > others have contacted various media representatives, in an attempt to > get them to focus a spotlight on Intuit, and let people know that > Intuit is broadcasting their SSN, without their knowledge. And of > course, I'm posting Usenet articles in the privacy newsgroups, as well > as the newsgroup where most Quicken discussion occurs, > comp.os.ms-windows.apps.financial. > > If you are using Intuit's Online Bill Payment service, and are > concerned about this, please call Intuit and express your displeasure. > The number for the Online Bill Payment service is 708-585-8500. Also, > call your bank, and inform them as to what's going on. Finally, write > to your local (or national) newspaper, let them know about this, and > ask them to cover this in their paper. > > It appears that the only way Intuit is going to address this is by > getting some negative publicity, since customer complaints don't seem > to carry enough weight. I wish they were more reasonable, but that > just doesn't seem to be happening here. So be it --- they want a > fight, they've got one.

2 1

Re: CFS and Linux
by Alan Olsen 17 Dec '03

17 Dec '03

At 11:40 PM 12/20/95 -0500, Matt Blaze wrote: >I'm told that all version of CFS since 1.0.4 (the latest is 1.3.1) >do work out-of-the-box under *some* releases of Linux and with some >coaxing on the others. I am wondering if he is compiling for ELF. That seems to throw a good size monkey wrench into just about every piece of software out there. (At least the ones that have not been written to take the ELF paculiarities into account.) >I'm not sure exactly what problem you're having, but the most common >CFS-Linux problem that people complain about has to do with the rpcgen >output not being in the format expected by the rest of CFS. There >seem to be two things you can do about this: get a version of rpcgen >that generates the "standard" (original Sun) names for the functions it >generates, or just grab the rpcgen output from the cfs-users mailing list >archive ("echo help | mail cfs-users-request@research att.com" for details). I think you may be right on this one. I have heard of a few other things having problems with Linux's version of rpcgen. (The names of which are not coming to mind... Need more coffee.) [rest of reply deleted because I had nothing to say about it] ObNoise: >NB to "Bill Gates" and friends: To save you the trouble of pointing it out, >I hereby admit that I'm a commie-fascist brainwashed sold out member of the >military-industrial complex who has been programmed by his masters to >infiltrate the cypherpunks in order to sap and impurify their precious >bodily fluids. I think that the mention of Mr. Bill as a "good guy" is the most effective use of agent provoceteur-type behaviour I have seen on this list yet. We know who Mat and Jeff work for. Who do the anon-flamers work for? | Remember: Life is not always champagne. Sometimes it is REAL pain. | |"The moral PGP Diffie taught Zimmerman unites all| Disclaimer: | | mankind free in one-key-steganography-privacy!" | Ignore the man | |`finger -l alano(a)teleport.com` for PGP 2.6.2 key | behind the keyboard.| | http://www.teleport.com/~alano/ | alano(a)teleport.com |

1 0

Re: Cypherpunks resumes?
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 7:55 AM 12/21/95, Anonymous wrote: >Is there any chance of seeing a Cypherpunks 'Rogues Gallery' of sorts >in the archives anytime soon? It would be nice to see a face connected >to the postings here. Some of us don't get the chance of getting out >west for the parties, The only other thing I know about Tim May besides >being one of the Fathers of the Cypherpunks is that he was a naked hippie >in a hot tub at some party that Robert Hettinga was at some weeks ago, > >That doesn't paint a good picture for me. - But, "Anonymous," we don't even know which of the many "Anonymous" ones you are, so why should we go out of our way to provide images, resumes, dossiers, etc., to you? In any case, many of the folks on this list have elected to have Web pages, often with images of themselves, their SOs, their pets, their computers, and so on. Perhaps their images will paint a better picture for you. (I note that the last "Anonymous" person concerned with getting the "real" pictures of people was S. Boxx, or maybe Pablo Escobar, I forget.) (I have not spent time generating a "home page." I see the burgeoning shelves of "HTML Bible" self-help books and see more and more people spending time gussying-up their home pages. People are even putting their personal diaries on the Web, plus all sorts of personal stuff that is finding its way into compiled dossiers. Not for me. I prefer my essays to be what goes into my dossiers.) Or, as our esteemed Gothamite might reJoyce: Erudite, profligate, disputacious -- indistinguishable from many other publicity-saving levitationisms. 'Tis superficially an expurgated part of the Ruby Ridge-slippered Great Oz divulgation. Ostentatiously, the preterite few surf the gilt-edged waves while Jose Sixpacks languish in spider-webbed Quayle-spelt ghettoes populated by home page homeys. For further emendations and emissions, behave normally and reply with a blank message labelled: XMAS_troll --You Know Who

2 1

Massey, CEO of Compuserve, on Internet
by Mark Neely 17 Dec '03

17 Dec '03

>Wow! I am watching the CEO of Compuserve being interviewed on CNBC, >explaining how his company is "taking the high road by complying with the >laws of Germany" in removing access to 200 Usenet groups. >Timothy C. May I assume that C$ is only filtering the newsfeed as it hits German shores? Please tell me they aren't denying access to these "banned" newsgroups for all users worldwide! Mark ___ Mark Neely - accessnt(a)ozemail.com.au Lawyer, Professional Cynic Author: Australian Beginner's Guide to the Internet Work-in-Progress: Australian Business Guide to the Internet WWW: http://www.ozemail.com.au/~accessnt

2 1