- cypherpunks-legacy - lists.cpunks.org

Re: Saw this on CNN: Anonymous Stock tips over IRC as bad??
by Deranged Mutant 17 Dec '03

17 Dec '03

On 3 Jun 96 at 15:18, Jeff Barber wrote: > I trust it won't stun you to find that many, many large and even small > corporations -- including my current employer [*NOT* SecureWare, BTW, > despite the email address] -- actually encourage their employees to buy > stock by offering stock purchase plans as a benefit of employment. They > even make it convenient by deducting purchases from one's paycheck. [..] There's a difference between a) buying stock in your employer's company generally [above example] and b) buying stock in your employer's company because your department is working on something that will raise the stock value etc. etc. --- No-frills sig. Befriend my mail filter by sending a message with the subject "send help" Key-ID: 5D3F2E99 1996/04/22 wlkngowl(a)unix.asb.com (root@magneto) AB1F4831 1993/05/10 Deranged Mutant <wlkngowl(a)unix.asb.com> Send a message with the subject "send pgp-key" for a copy of my key.

1 0

MOSS vs. S/MIME vs. PGP/MIME Matrix (fwd)
by Adam Shostack 17 Dec '03

17 Dec '03

----- Forwarded message from Rik Drummond ----- >From ietf-request(a)IETF.CNRI.Reston.VA.US Thu May 30 09:26:53 1996 Message-Id: <v02130500add3465435b8(a)[199.184.212.213]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 30 May 1996 08:05:48 -0500 To: ietf-ediint(a)imc.org, Electronic Data Interchange Issues <EDI-L(a)uccvma.ucop.edu>, ietf(a)CNRI.Reston.VA.US Sender: ietf-request(a)IETF.CNRI.Reston.VA.US From: Rik Drummond <drummond(a)onramp.net> Subject: MOSS vs. S/MIME vs. PGP/MIME Matrix Source-Info: From (or Sender) name not authenticated. The EDI over Internet (EDIINT) working group will recommend standards which facilitate "EDI interoperability over Internet - Now" during the third quarter of 1996. Two of the many requirements are the implementation of encryption and signature for EDI transactions using existing standards/products, such as: MOSS, S/MIME, PGP/MIME and DMS. These four standards/products "generally" fit the needs of the EDIINT effort. We must choose those that best fit our requirements. A Comparison Matrix compares the products/standards across over 30 technical and business areas. Please take time to contribute your expertise to the effort by commenting on the existing information. This matrix is the basis for determining which security products/standards/algorithms to use for EDI over Internet. The matrix is also a significant tool for selling our final recommendation to EDI business product development management. The comparison matrix is in html format at http://ftp.sterling.com/edi/ietf-ediint/decision.html. Thank you. Rik Drummond Chair EDIINT ------------------------------------------------------ | Rik Drummond - The Drummond Group | | 5008 Bentwood Ct., Ft. Worth, TX 76132 USA | | Voice: 817 294 7339 Fax: 817 294 7950 | ------------------------------------------------------ ----- End of forwarded message from Rik Drummond ----- -- "It is seldom that liberty of any kind is lost all at once." -Hume

1 0

e$: Interbank Digital Cash Clearing, Better Living through
by Robert Hettinga 17 Dec '03

17 Dec '03

--- begin forwarded text Date: Mon, 3 Jun 1996 21:03:16 -0400 To: Multiple Recipients of e$pam <e$pam(a)intertrader.com> From: e$pam(a)intertrader.com (e$pam) Reply-To: e$(a)thumper.vmeng.com X-Comment: To unsubscribe, send an email to e$pam-request(a)intertrader.com X-Comment: containing the command "unsubscribe e$pam" Precedence: Bulk Subject: e$: Interbank Digital Cash Clearing, Better Living through X-orig-from: Robert Hettinga <rah(a)shipwright.com> X-e$pam-source: owner-ecash(a)digicash.com Forwarded by Robert Hettinga ----------------------------------------------------------------------- X-Sender: rah(a)tiac.net Mime-Version: 1.0 Date: Mon, 3 Jun 1996 17:34:31 -0400 To: ecash(a)digicash.com From: Robert Hettinga <rah(a)shipwright.com> Subject: e$: Interbank Digital Cash Clearing, Better Living through Walletware, Microintermediation, Net.Currencies and ECM Sender: owner-ecash(a)digicash.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- e$: Interbank Digital Cash Clearing, Better Living through Walletware, Microintermediation, Net.Currencies and ECM June 3, 1996 Boston,Massachusetts People have asked me what I think about interbank digital cash clearing, and I say I'm all for it. Flippant comments aside, I'm not sure I can add anything to the discussion, but I'll take a shot at it. It's easy to argue that there's no real need right now for *on-net* interbank clearing, especially with online cash. If you handle the transactions right, the merchant just verifies and deposits cash as it comes in. This works especially well with the underwriter-as-internet-ATM-machine model I like to use in discussion. (I include that here only by reference, as I've beat it to death. The e$ home-page is http://thumper.vmeng.com/rah/ ) If the trustee behind the underwriter is, well, trusted, to do deposits as well as withdrawls, then the "problem" of interbank clearing on the net itself goes away. Actually, we just translate it into "normal" world of book-entry banking transactions, and the trustee does the interbank clearing there. Same as it ever was. In this scenario, if the customer presents a certificate requiring change, the change can be issued in the same transaction as the deposit of the rest of the transaction's proceeds. Frankly, in a world of ubiquitous networks, this is clearly the way to go for merchants of any means whatsoever, because it's completely safe for them, and it doesn't matter who the underwriter of the cash is. With the proper level of software abstraction, it may not even matter what the cash protocol is. However, networks are a long way from ubiquitous, and that means offline transactions for a lot of cases. Fortunately, if we want to think about offline transactions, we can pilfer some more ideas from, as usual, the market for traveller's checks. When a merchant deposits a traveller's check, her bank clears it like any other check. That's possible because not only is the check secured, but it is hard to replicate. Most importantly, American Express offers a virtual guarantee of payment even if the checks are proven to be lost or forged, which speaks volumes about the susceptability of the system to any large-scale fraud. However, in the unlikely event that AmEx goes out of business, the merchant, not the bank, would be left holding the bag, just like she would be with a bounced check. Obviously, the same thing happens with money orders, a market in which there are many more issuers. All banks issue money orders, but traveller's checks require large consumer marketing campaigns, so there are fewer underwriters of them. So, if it is possible to build linkages between digital cash and the checking system through the merchant's bank, we might have another solution. Fortunately, this is no problem. A merchant takes in various forms of off-line cash all day and deposits it electronically at the time she deposits her other money. The bank validates, clears, and deposits the cash right there at the teller/ATM, through it's connections to the net. This is (barely!) analogous to what happens to a traveller's check or money order, which is deposited and sometimes physically flown to the issuer's bank to clear, and paid back to the depositor by fed wire to settle the transaction. Making change for the transactions themselves in this scenario is problematic, but the merchant can just hand back physical cash, just like she does with traveller's checks. An all-electronic variant on this "mixed-money" change method is for the merchant to hand back whatever digital-note change she has, regardless of who issued, and this implies a lot of preconditions, but it's not as scary as it looks, which we'll see in a little bit. Right now, when we talk about the need for interbank clearing, a lot of people seem to be talking about offline cash. As we saw, online clearing is pretty much a geodesic process, because you're connected straight to the underwriter of the cash you're using for the transaction under way. It's hard for me to see any need for on-net intermediaries for online cash, at least for the time being, because the trustee, the actual financial intermediary in the transaction, is hooked into the "physical" financial system of banks, ATM networks, and central-bank fund-wires. I'll talk about on-the-net financial intermediaries a bit later, though, and there might be one wild card, but I'm not sure. In the same way that I claim that certificate-based clearing and settlement is always going to be cheaper than book-entry methods, I think that offline cash is always going to be cheaper at the margin than online cash. The risk of offine transactions is always going to be double-spending, and that has to be traded against convenience, lower cost of not needing net access and the absolute anonymity you can get by not having to ever reveal yourself to even the underwriter of the digital cash in question. My claim of "marginally cheaper" for offline cash is strictly because of the lack of a net connection, but this cost-component will continue to fall into the forseeable future, so it will be less of an issue. Today, however, with only tens of millions of people on the net out of a world population in the billions, off-line digital cash has a significant cost advantage, and as long there's a bank with in a few transactions' proximity to the offline transaction in question, I think it can still be pretty safe to do offline digital cash transactions. Precicely because we're only a transaction-hop or two from an on-line transaction, double spending is reduced to a physical phenomena at the smartcard-to-smartcard level, which is much easier to deal with. The hoary old bugbear people like trot out at times like this, that of a bajillion salami-slice transactions done simultaneously all over the net all at once, goes back under the bed -- or back into the monster closet -- where it belongs. (Speaking of bugbears, remember, the problem of someone stealing a bank's key, and literally printing free money, is more a problem of issuing digital cash batches with expiry dates than anything else. More to the point, the problem belongs to a single underwriter, and not to a robust market with many competing underwriters.) Anyway, the upshot of the double-spending problem is that it assumes a world of strictly offline transactions, which is almost as ludicrous as a world of strictly online transactions. ;-). Any robust and marketable system of digital cash will need to be able to do both. Like I said above, the transaction handling mechanisms are everything in a multi-underwriter, multi-trustee, and even multi-certificate-protocol regime. We need to have a set of standards for digital cash clearing and settlement which makes the actual issuer as transparent as possible to the transaction's participants. After all, that's what we have with checks. The bank the check's drawn on doesn't really matter. To a lesser extent, neither does the issuer of a traveller's check or money order. Who printed the check *certainly* doesn't matter. That's about where we want to be with digital cash. If I want to buy something from you with ecash, the last thing we should care about is the mechanics of the transaction, and *that* includes who the issuer of the cash is, who the trustee is who's going to do the interbank settlement out in the book-entry world, who the protocol designer is who invented the type of cash we're using, who the software developers were who developed my wallet and your register. None of that. We just want to settle the trade. Better living through walletware. That means that we need think about multi-underwriter clearing from the outset, preferrably at the merchant level, and I'm sure that's what Digicash is moving towards. Digicash's walletware and registerware, or anyone else's for that matter, should be able to transact business with ecash of any form, without discrimination. If I spend some ecash with you, your cash register should take any and all combinations of my Deutche-ecash, or my Twain-ecash, or my Finn-ecash, validate them online with their underwriters (whose responsibility for transaction clearing turnaround should make speed a major selling point to their customers), and hand me back change however I want it, choice of underwriter (or not) and all. In fact, if everything works out, and markets for digital cash underwriting become efficient and competitive, then *who* underwrites my ecash becomes less of an issue to me over time. One form of ecash is as good as another, because it all interoperates. So, if we assume that walletware takes different protocols, it seems that the dominant digital cash protocol would be that which operates best from the *underwriter's* standpoint, which is where it should be, since they're the ones whose reputations are being risked, "rented", as it were. Okay. Let's look quite a few years ahead, to a time when most money that comes onto the net stays here and just gets moved around, to digital bearer bonds, or to digital mutual fund certificates, or whatever. Let's say that Tatsuo Tanaka's scenario has come to pass. That is, because the money's not leaving the net as soon as the transaction takes place, like we've been talking about, the digital cash underwriters and trustees, most likely with the knowing collusion of users who want to pay lower purchase discounts, start "creating" money by issuing cash against fractional, instead of 100% reserves. More to the point, to follow Tanaka some more, a panic or two brought about by these shenanigans has caused the underwriters to police themselves by creating some kind of independent currency control for various associations of fractional-reserve underwriters, much in the same way that fractional reserve bank panics were handled prior to the advent of central banking. We may even have several full-blown internet currencies, controlled by currency boards of some kind. I'm not talking about nation-states, here, either. All of this could be done on a private basis. Real live private currencies, offered by an association of digital cash underwriters. This is a *long* way off, but do you see what I'm getting at here? What we end up with is an on-the-net interbank clearing system, doing just what the book entry system does now, only without governments or central banks in the middle. We have intermediaries in the form of a board which manages the quantity of a given private currency based on "foriegn" reserves, that is, the holdings in its member banks in the *other* currencies, which prevents monitary inflation, and that's one place where the "interbank" clearing takes place. In this environment, we also have currency hedgers and speculators, who make (or save) money by trying to figure out where currencies of various kinds are going to go relative to one another. These days we have institutions moving large amounts of currencies around, doing insecure trades on secure networks. However, the technology of digital bearer certificates and ubiquitous public networks could enable a legion of very small autonomous entities to do the same kinds of activity that the big boys do now. So we don't get "disintermediation", which lots of people see right now with the merger of your local savings bank into a big conglomerate, or your local stockbroker getting bought or put out of business by a discount broker or mutual fund. We end up with "microintermediation". Actually, I've written about the same idea elsewhere, of underwriting "bots" providing ubiquitous auction markets for things like personal digital bearer bonds, etc., but in this case we have a bunch of trading 'bots making secondary markets in currency, hedging and speculating on price fluctuations for money, all like a bunch of microscopic George Soroses. Like George Soros and his famous takedown of the EU's exchange mechanism, these bots would be who actually "determine" the price of a given net.currency versus another, and not the net.currency boards at all. Okay. I've wandered way out here on a limb, and I'm going to climb off of it soon, before I either fall or someone cuts it off. :-). However, before I go, let's look at something which actually happened, and which may be a pointer to what could happen again soon, without too much trouble. I'm talking about ecm, or the electronic cash market trading list. Last summer, when I got back from my New Orleans trip, I was up in Montana hanging out while my wife was at an educator's conference, and Lucky Green sends me e-mail about having just sold, for cash, some of the demo "cyberbuck" certificates that Digicash was issuing at the time. I commented about this to cypherpunks, one thing led to another, and the next thing I knew, Rich Lethin had started up a mailing list and set up a protocol for trading these beta-certificates for cash over that list. He named the list ecm. (Send "info ecm" in the body of a message to majordomo(a)ai.mit.edu, if you want to see what the fuss was all about.) It was used sporadically up to the time when, you guessed it, Mark Twain came on line with *actual* digital cash, and people stopped trading beta-certificates altogether. I can't even remember what the last settlement price was, but it was pennies on the dollar. Actually, now that I remember it, there was a period where the beta-certificates were traded for real Mark Twain ecash on someone's web-page and then announced on ecm, but things have pretty much gone moribund on ecm lately. I haven't seen a trade go across in many months. ECM is the "wild-card" exception to using the current banking system for interbank digital cash clearing. The one that I was talking about above, after I said we didn't really need an interbank clearing mechanism on the net itself. If someone wanted "clear" these different versions of ecash on the net some day, they could just take positions in both the Finnish, Mark Twain, and eventually Deutchebank certificates, and run a little currency exchange operation for fun, and maybe profit, between the three by announcing their bid/ask prices on ecm in both certificates. Hint: buy low, sell high. :-). They could even do currency-speculation-by-proxy by taking different positions in these certificates if they wanted to. It may even be that someone could do this and make a living at it, someday, if enough digital cash was used on the net, particularly if they could do it cheaper than it would cost someone to "deposit" their cash, through an underwriter, into their own bank account. Would income or capital gains taxes be considered part of that deposit "cost"? As Francis Urquart (RIP) used to say, "*You* might say that, but *I* couldn't possibly comment." Cheers, Bob Hettinga -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMbNaLPgyLN8bw6ZVAQHf6QP/aDY1bhj+ZaG/yTGqezDpnuYYn2Gp2lVE QTTb8z5e9CLWDRMfLCEsFYs8OoXaWNa6NWmDTnpM44NuDawzfqmywWV4RIUyTp1B /ArcruU7z1LiCJUFI8XByGwQiGKsqVRVaoybf2QXP2NGeNSYuYol8s6umcmznzbR cXqvCdBMW/s= =YW/2 -----END PGP SIGNATURE----- ----------------- Robert Hettinga (rah(a)shipwright.com) e$, 44 Farquhar Street, Boston, MA 02131 USA "If they could 'just pass a few more laws', we would all be criminals." --Vinnie Moscaritolo The e$ Home Page: http://www.vmeng.com/rah/ -------------------------------------------------- The e$ lists are brought to you by: Take Your Business Online with Intertrader Ltd, Edinburgh, U.K. Visit http://www.intertrader.com or email info(a)intertrader.com Making Commerce Convenient (tm) - Oki Advanced Products - Marlboro, MA Value-Checker(tm) smart card reader= http://www.oki.com/products/vc.html Where people, networks and money come together: Consult Hyperion http://www.hyperion.co.uk info(a)hyperion.co.uk See your name here. Be a charter sponsor for e$pam, e$, and Ne$ws! See http://thumper.vmeng.com/pub/rah/ or e-mail rah(a)shipwright.com for details... ------------------------------------------------- --- end forwarded text ----------------- Robert Hettinga (rah(a)shipwright.com) e$, 44 Farquhar Street, Boston, MA 02131 USA "If they could 'just pass a few more laws', we would all be criminals." --Vinnie Moscaritolo The e$ Home Page: http://www.vmeng.com/rah/

1 0

Re: Java Crypto API questions
by shamrock＠netcom.com 17 Dec '03

17 Dec '03

At 16:22 6/3/96, jim bell wrote: >A signature is just that: A signature. It doesn't encrypt or decrypt. It >doesn't even ALLOW the system it's in to encrypt or decrypt, because there >are numerous encryption programs written that have no need for such a >signature. If no program existed which _used_ that signature, nobody would >think twice about exporting it. > >The fact is, it is LEGAL to import encryption code into the US. It is LEGAL >to generate an hash of that code, and it is LEGAL to export that hash. To >believe otherwise is to broadly expand the scope of export laws far beyond >what they were intended to mean. First, the ITAR are not laws, but regulations. Second, there are many that believe that applying ITAR to crypto software is already expanding the scope of the regulations far beyond what they were intended to mean. Let us not forget that the ITAR were written to prevent the proliferation of military technology. Applying them to mass market crypto software does not aid this original goal in any way. At one point, the existing ITAR began to be used to further a cause utterly unrelated to their original intend: limiting the domestic market penetration of strong crypto systems. Disclaimer: My opinions are my own, not those of my employer. -- Lucky Green <mailto:shamrock@netcom.com> PGP encrypted mail preferred.

1 0

Re: CWD: "Jacking in from the "One that Got Away" Port
by Deranged Mutant 17 Dec '03

17 Dec '03

On 3 Jun 96 at 22:19, Declan McCullagh wrote: > (By Brock Meeks / brock(a)well.com / Archived at http://www.cyberwerks.com/) > CyberWire Dispatch // Copyright (c) 1996 // > Jacking in from the "One that Got Away" Port: [..] > That key length stuff is just so much gibberish to those playing > without a scorecard, so let me drill down on it for you. Basically, > the longer the key length, the harder it is for a message to be broken > by "brute force" automated attacks. Current U.S. laws prohibit the > export of any encryption device with a key length longer than 40-bits, > or roughly the equivalent of Captain Crunch decoder ring. For hardcore > math types, I'm told that a 1024-bit key length is 10 to the 296th > power more difficult to break than 40 bits. Too bad he got caught up in the gibberish. --- No-frills sig. Befriend my mail filter by sending a message with the subject "send help" Key-ID: 5D3F2E99 1996/04/22 wlkngowl(a)unix.asb.com (root@magneto) AB1F4831 1993/05/10 Deranged Mutant <wlkngowl(a)unix.asb.com> Send a message with the subject "send pgp-key" for a copy of my key.

1 0

Greetings from Star+Globe
by poh＠iss.nus.sg 17 Dec '03

17 Dec '03

Dear Sir/ Madam, Greetings from Star+Globe Technologies! Thank you for accessing & using our WinMASS. It is indeed our pleasure to bring you the multilingual world at your fingertips. To pursue our objective of delivering the best and most cost effective solution for all your multilingual computing needs, we appreciate your support and encouragement. May we take this opportunity to seek your views and suggestions on WinMASS, based on the Cyber Launch of May 15th, 1996 wherein you have registered. 1.Did you have any problems while downloading WinMASS? Please specify. 2.Have you tried and explored WinMASS? 3.Is WinMASS informative and complete? did you find anything missing? 4.With what application did you use WinMASS? were you satisfied? 5.Have you used / using any other Multilingual Software? 6.What is your working platform for Hardware and Software? 7.What features do you like most about WinMASS? 8.What additional features would you like to have? 9.Do you have any specific querries that you would like us to answer? 10.Any other valuable feedback is welcome. We want to improve our service to you. Your support and cooperation is highly desired and will be helpful to do our best. Thank you and look forward to receiving your valuable information at any of the following e-mail address: info(a)starglobe.com.sg sales(a)starglobe.com.sg venki(a)starglobe.com.sg Best Regards, Venki Char

1 0

Re: cycle market
by frantz＠netcom.com 17 Dec '03

17 Dec '03

At 11:14 AM 6/4/96 -0400, SINCLAIR DOUGLAS N wrote: >Graphical rendering is one place where I might like a cycle >market. Finite element simulation is another. Sinclair mentions some of my favorites. Others are: (1) Attacking RSA-nnn challanges. (2) Brute forcing 56 bit keys to demonstrate that 1DES is obsolete. ------------------------------------------------------------------------ Bill Frantz | The CDA means | Periwinkle -- Computer Consulting (408)356-8506 | lost jobs and | 16345 Englewood Ave. frantz(a)netcom.com | dead teenagers | Los Gatos, CA 95032, USA

1 0

Re: Fate of Ecash if RSA is cracked?
by norm＠netcom.com 17 Dec '03

17 Dec '03

At 8:01 AM 6/3/96, Perry E. Metzger wrote: >Dr. Dimitri Vulis writes: .... >> This'll happen, probably sooner than later. > >Why do you assume that? There are plenty of problems that are >provably not solvable in non-exponential time even if P=NP. What makes >you think this one is going to be solved? > >.pm The "Idea Futures" forum has established odds on this. The current odds are currently 60% that a 1024 bit number will be factored by 2010 and 30% that a 512 bit number will be factored by 1997. See <http://if.arc.ab.ca/IF.shtml> for Idea Futures and <http://if.arc.ab.ca/bin/summary> for odds for various questions.

4 4

Re: CWD: "Jacking in from the "One that Got Away" Port
by jim bell 17 Dec '03

17 Dec '03

At 10:19 PM 6/3/96 -0500, Declan McCullagh wrote: >(By Brock Meeks / brock(a)well.com / Archived at http://www.cyberwerks.com/) > > > CyberWire Dispatch // Copyright (c) 1996 // > A virtual tactical nuke was hurled into the arcane subculture of > encryption technology Monday when RSA President Jim Bizdos revealed > that his company's Japanese subsidiary had developed a monster chipset > capable of scrambling voice and data real time with a so-called "key > length" of up to 1024 bits. I don't mean to be overly critical, but why not provide for the possibility of longer keys? The RSA key only has to be exchanged and decoded once per call, presumably, which suggests that there shouldn't be a problem to do 2048-bit keys. Admittedly, 1024 bits will be good for many years, but... > That key length stuff is just so much gibberish to those playing > without a scorecard, so let me drill down on it for you. Basically, > the longer the key length, the harder it is for a message to be broken > by "brute force" automated attacks. Current U.S. laws prohibit the > export of any encryption device with a key length longer than 40-bits, > or roughly the equivalent of Captain Crunch decoder ring. For hardcore > math types, I'm told that a 1024-bit key length is 10 to the 296th > power more difficult to break than 40 bits. I sure do wish they'd get things like this a bit more accurate... Oh, well, I suppose it doesn't really matter... Jim Bell jimbell(a)pacifier.com

3 2

Paper about electronic cash and common currencies available
by Robert Hettinga 17 Dec '03

17 Dec '03

--- begin forwarded text Sender: e$(a)thumper.vmeng.com Reply-To: Wolfgang Roeckelein <wolfgang.roeckelein(a)wiwi.uni-regensburg.de> Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) Precedence: Bulk Date: Tue, 4 Jun 96 11:14:41 +0200 From: Wolfgang Roeckelein <wolfgang.roeckelein(a)wiwi.uni-regensburg.de> To: Multiple recipients of <e$(a)thumper.vmeng.com> Subject: Paper about electronic cash and common currencies available Hello everybody, our paper titled "A Common Currency System for Spontaneous Transactions on Public Networks" is available online under http://www.whu-koblenz.de/~wolfgang/CommonCurrency/ Perhaps somebody might be interested. Thank you for your attention, Wolfgang Roeckelein --- Dipl.-Wirtsch.Inf. Voice: +49 941 943 2998 Wolfgang Roeckelein Fax: +49 941 943 4986 Uni Regensburg E-Mail: roeckelein(a)wi.whu-koblenz.de Universitaetsstr. 31 Wolfgang.Roeckelein(a)wiwi.uni-regensburg.de D-93053 Regensburg (MIME and NeXTmail ok) Germany WWW: http://www.whu-koblenz.de/~wolfgang/ GCM/B d-- s: a- C++ US+++$ UX+++ P+ L E? W++ N++ w-- O-(++) M+ !V PS++ PE Y+ PGP(++) t+ 5? X? R+ tv b++ DI D++ G e+++>++++ h+ r++>% y? (Geek Code V3.x) --- end forwarded text ----------------- Robert Hettinga (rah(a)shipwright.com) e$, 44 Farquhar Street, Boston, MA 02131 USA "If they could 'just pass a few more laws', we would all be criminals." --Vinnie Moscaritolo The e$ Home Page: http://www.vmeng.com/rah/

1 0