Cypherpunks, I tried to send this out earlier, but I haven't seen it at my site. I've been having problems with messages either not getting out or not being delivered back to me, so I don't know if this made it out to you. If not, here it is. If so, I'm sorry for the duplication. --Tim Forwarded message: From: tcmay (Timothy C. May) Message-Id: <199401220929.BAA27006@mail.netcom.com> Subject: Re: Remailers: The Next Generation To: cypherpunks@toad.com Date: Sat, 22 Jan 1994 01:29:19 -0800 (PST) Cc: tcmay (Timothy C. May) Hal Finney has added many useful points:
I don't know if charging for messages can be made to work. Karl has a remailer which requires digital tokens. You can get them for free just by sending an email message. But I'll bet almost no one uses them. Why should they, when there are free ones?
That is the big problem. The free ones undercut the pay-per-use
Good point. My hunch is that "nothing is free" and the usual evolution will be followed: initially free-but-poorly-supported capabilities, followed by some flavor of commercial services which are in competition with the "free" services, and then a widening gap in quality/robustness between the free and fee services. For example, my own Netcom service costs $17.50 a month and competes with local free or nearly free BBS services that offer some form of Internet access. The advantages of Netcom are sufficient to make it worth paying for. Another example, in a different situation, is the explosive increase in bookstores in the last 20 years, even when libraries offer books for free. People _will_ pay for convenience, features, robustness, etc. It may be a marketing struggle, but eventually fee-based services seem to win out over free-but-flaky systems.
remailers. Unless the pay remailers offer significantly more features and advantages to the users, they won't be used. Especially if we are talking about actually mailing physical cash to the remailer operators in order to receive tokens, this will be terribly inconvenient and will further raise the threshold barrier against for-pay remailers.
I agree this is a speed bump. In fact, most folks are making very little use of existing features (chained hops, encryption) and overall volume seems pretty low. Part of my reason for proposing a formal "second generation" is that enough new features, and greater ease of use (standards, scripts, automatic selection of routings, ratings services) may tip the balance toward wider use. Also, the loss of penet-type servers with a centralized point of attack (e.g., Julf's machine) may suddenly and urgently shift the burden onto Chaumian-style distributed systems. (Just a hunch I have.)
So, the question is whether the value can be made large enough. Most of Tim's comments are focussed on the security of the remailers. For some applications this is important, particularly the more world- shaking ideas we have discussed. (And despite the skepticism I expressed last week about the degree to which cryptography can change the world, I do believe it can be a strong force for positive change.) If people are fighting for freedom against a powerful adversary, they will need the kind of security Tim is talking about.
Yes, I confess that my slant on things is toward the "ideal mix," that extremely strong system of distributed mixes that will provide the underpinning for the untraceable system we all want (for the reasons of protecting privacy in a surveillance society that Hal mentioned) and for the more radical stuff that some of us want. Working toward the ideal digital mix seems to be the right thing to do, as a strong foundation will make so many other things easier. Making the systems easier to use is of course also important, and several of my points were oriented toward this. But I agree my focus is on making the next generation more bullet-proof. (As an aside, more people will be willing to run turn-key remailers if they are convinced the remailer functions are sufficiently robust to head off charges that they knew what was flowing through their remailers, that the system won't barf and dump a bunch of messages into the trash or into their machine logs, and that the software will run without their involvement. Such robustness will allow and encourage the spread of cheap remailer boxes. Price competition on remailer rates will make the burden of paying drop. This is the hope, at least.)
now. I frankly don't see improved security as a major problem that needs to be addressed in the short term. It's worth mentioning that
Perhaps Hal is right, perhaps not. But regardless of the exact priorities, agreeing on some standards, some scripting conventions, and encouraging a "pinging service" (like what Karl Barrus does with his periodic summary, but with more statistics on delays, packet sizes, etc.) seem like some things we need to do. Thinking of several of these as aspects of the next plateau, the "second generation," may help to focus energies on adding features.
In my opinion, what the remailer network needs is, first, standardization, as Tim has proposed. Secondly, it needs reliability and robustness. Third, it needs to be easier to do two-way messaging.
I agree with all of this. I did not address two-way mail, using either the "onions" (a kind of return-rely envelope) proposed by Eric Messick and Hugh Daniel about a year ago, or the "pools" described by Miron Cuperman. (Readers may recall that the "BlackNet" experiment I ran called for respondents to encrypt their replies, with no mention of their names or addresses, to the public key of BlackNet and then post the cyphertext to one of several groups...thus was 2-way anonymous communication created.) One project that could be interesting is this: a merger or hybrid of the distributed, hard-to-kill Cypherpunks remailers and the wildly successful, centralized, easier-to-kill penet system of Julf. That is, multiple penet-type sites, using mixes between. Or meshed in other ways. The idea is to make sure that greater security against legal and governmental action is built-in. (I realize Julf's system keeps a mapping between real IDs and pseudonyms, and this centralized mapping is the point of attack. Still, some decentralization, some scattering across multiple national borders, would be useful. Perhaps something involving secret-sharing protocols.) Oh, and I agree with the comments a couple of people made that running constant traffic between remailers is a good way to ensure message latency does not result in excessive delays. We've actually talked about this before, but nothing has been done on this. One of the problems (also a strength) is that our various remailers are all run by different people, on different machines, etc. They are not like Western Union telegraph offices, with coordinated policies. Setting up regular communications, robust connections, is thus not as easy as it might be with uniform remailers. (A speculative solution: a group of remailer sites can agree to form a kind of "guild," agreeing to work together to keep uptimes high, use standardized software, etc. All voluntary. Like franchises of McDonalds. The participating remailers could agree to run traffic at certain rates between their machines, work together to ensure adequate robustness, issue a report on all of their machines, etc. Remailers that don't want to participate can still be used, but would likely have poorer interaction with other machines and might eventually lose business.) --Tim May -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power:2**859433 | Public Key: PGP and MailSafe available. -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power:2**859433 | Public Key: PGP and MailSafe available.