8.6.1. What are remailers? 8.6.2. Cypherpunks remailers compared to Julf's + Apparently long delays are mounting at the penet remailer. Complaints about week-long delays, answered by: - "Well, nobody is stopping you from using the excellent series of cypherpunk remailers, starting with one at remail@vox.hacktic.nl. These remailers beat the hell out of anon.penet.fi. Either same day or at worst next day service, PGP encryption allowed, chaining, and gateways to USENET." [Mark Terka, The normal delay for anon.penet.fi?, alt.privacy.anon-server, 1994-08-19] + "How large is the load on Julf's remailer?" - "I spoke to Julf recently and what he really needs is $750/month and one off $5000 to upgrade his feed/machine. I em looking at the possibility of sponsorship (but don't let that stop other people trying).....Julf has buuilt up a loyal, trusting following of over 100,000 people and 6000 messages/day. Upgrading him seems a good idea.....Yes, there are other remailers. Let's use them if we can and lessen the load on Julf." [Steve Harris, alt.privacy.anon-server, 1994-08-22] - (Now if the deman on Julf's remailer is this high, seems like a great chance to deploy some sort of fee-based system, to pay for further expansion. No doubt many of the users would drop off, but such is the nature of business.) 8.6.3. "How do remailers work?" - (The MFAQ also has some answers.) - Simply, they work by taking an incoming text block and looking for instructions on where to send the remaining text block, and what to do with it (decryption, delays, postage, etc.) + Some remailers can process the Unix mail program(s) outputs directly, operating on the mail headers - names of programs... + I think the "::" format Eric Hughes came up with in his first few days of looking at this turned out to be a real win (perhaps comparable to John McCarthy's decision to use parenthesized s-expressions in Lisp?). - it allows arbitary chaining, and all mail messages that have text in standard ASCII--which is all mailers, I believe--can then use the Cypherpunks remailers 8.6.4. "What are some uses of remailers?" - Thi is mostly answered in other sections, outlining the uses of anonymity and digital pseudonyms: remailers are of course the enabling technology for anonymity. + using remailers to foil traffic analysis - An interesting comment from someone not part of our group, in a discussion of proposal to disconnect U.K. computers from Usenet (because of British laws about libel, about pornography, and such): "PGP hides the target. The remailers discard the source info. THe more paranoid remailers introduce a random delay on resending to foil traffic analysis. You'd be suprised what can be done :-).....If you use a chain then the first remailer knows who you are but the destination is encrypted. The last remailer knows the destination but cannot know the source. Intermediate ones know neither." [Malcolm McMahon, JANET (UK) to ban USENET?, comp.org.eff.talk, 1994-08-30] - So, word is spreading. Note the emphasis on Cyphepunks- type remailers, as opposed to Julf-style anonymous services. + options for distributing anonymous messages + via remailers - the conventional approach - upsides: recipient need not do anything special - downsides: that's it--recipient may not welcome the message + to a newsgroup - a kind of message pool - upsides: worldwide dist - to an ftp site, or Web-reachable site - a mailing list 8.6.5. "Why are remailers needed?" + Hal Finney summarized the reasons nicely in an answer back in early 1993. - "There are several different advantages provided by anonymous remailers. One of the simplest and least controversial would be to defeat traffic analysis on ordinary email.....Two people who wish to communicate privately can use PGP or some other encryption system to hide the content of their messages. But the fact that they are communicating with each other is still visible to many people: sysops at their sites and possibly at intervening sites, as well as various net snoopers. It would be natural for them to desire an additional amount of privacy which would disguise who they were communicating with as well as what they were saying. "Anonymous remailers make this possible. By forwarding mail between themselves through remailers, while still identifying themselves in the (encrypted) message contents, they have even more communications privacy than with simple encryption. "(The Cypherpunk vision includes a world in which literally hundreds or thousands of such remailers operate. Mail could be bounced through dozens of these services, mixing in with tens of thousands of other messages, re-encrypted at each step of the way. This should make traffic analysis virtually impossible. By sending periodic dummy messages which just get swallowed up at some step, people can even disguise _when_ they are communicating.)" [Hal Finney, 1993-02-23] "The more controversial vision associated with anonymous remailers is expressed in such science fiction stories as "True Names", by Vernor Vinge, or "Ender's Game", by Orson Scott Card. These depict worlds in which computer networks are in widespread use, but in which many people choose to participate through pseudonyms. In this way they can make unpopular arguments or participate in frowned-upon transactions without their activities being linked to their true identities. It also allows people to develop reputations based on the quality of their ideas, rather than their job, wealth, age, or status." [Hal Finney, 1993-02-23] - "Other advantages of this approach include its extension to electronic on-line transactions. Already today many records are kept of our financial dealings - each time we purchase an item over the phone using a credit card, this is recorded by the credit card company. In time, even more of this kind of information may be collected and possibly sold. One Cypherpunk vision includes the ability to engage in transactions anonymously, using "digital cash", which would not be traceable to the participants. Particularly for buying "soft" products, like music, video, and software (which all may be deliverable over the net eventually), it should be possible to engage in such transactions anonymously. So this is another area where anonymous mail is important." [Hal Finney, 1993-02-23] 8.6.6. "How do I actually use a remailer?" + (Note: Remailer instructions are posted _frequently_. There is no way I can keep up to date with them here. Consult the various mailing lists and finger sites, or use the Web docs, to find the most current instructions, keys, uptimes, etc._ + Raph Levien's finger site is very impressive: + Raph Levien has an impressive utility which pings the remailers and reports uptime: - finger remailer-list@kiwi.cs.berkeley.edu - or use the Web at http://www.cs.berkeley.edu/~raph/remailer-list.html - Raph Levien also has a remailer chaining script at ftp://kiwi.cs.berkeley.edu/pub/raph/premail- 0.20.tar.gz + Keys for remailers - remailer-list@chaos.bsu.edu (Matthew Ghio maintains) + "Why do remailers only operate on headers and not the body of a message? Why aren't signatures stripped off by remailers?" - "The reason to build mailers that faithfully pass on the entire body of the message, without any kind of alteration, is that it permits you to send ANY body through that mailer and rely on its faithful arrival at the destination." [John Gilmore, 93-01-01] - The "::" special form is an exception - Signature blocks at the end of message bodies specifically should _not_ be stripped, even though this can cause security breaches if they are accidentally left in when not intended. Attempting to strip sigs, which come in many flavors, would be a nightmare and could strip other stuff, too. Besides, some people may want a sig attached, even to an encrypted message. - As usual, anyone is of course free to have a remailer which munges message bodies as it sees fit, but I expect such remailers will lose customers. - Another possibility is another special form, such as "::End", that could be used to delimit the block to be remailed. But it'll be hard getting such a "frill" accepted. + "How do remailers handle subject lines?" - In various ways. Some ignore it, some preserve it, some even can accept instructions to create a new subject line (perhaps in the last remailer). - There are reasons not to have a subject line propagated through a chain of remailers: it tags the message and hence makes traffic analysis trivial. But there are also reasons to have a subject line--makes it easier on the recipient--and so these schemes to add a subject line exist. + "Can nicknames or aliases be used with the Cypherpunks remailers?" - Certainly digitally signed IDs are used (Pr0duct Cypher, for example), but not nicknames preserved in fields in the remailing and mail-to-Usenet gateways. - This could perhaps be added to the remailers, as an extra field. (I've heard the mail fields are more tolerant of added stuff than the Netnews fields are, making mail-to- News gateways lose the extra fields.) + Some remailer sites support them - "If you want an alias assigned at vox.hacktic.nl, one - only- needs to send some empty mail to <ping@vox.hacktic.nl> and the adress the mail was send from will be inculded in the data-base.....Since vox.hacktic.nl is on a UUCP node the reply can take some time, usually something like 8 to 12 hours."[Alex de Joode, <usura@vox.hacktic.nl>, 1994-08-29] + "What do remailers do with the various portions of messages? Do they send stuff included after an encrypted block? Should they? What about headers?" + There are clearly lots of approaches that may be taken: - Send everything as is, leaving it up to the sender to ensure that nothing incriminating is left - Make certain choices - I favor sending everything, unless specifically told not to, as this makes fewer assumptions about the intended form of the message and thus allows more flexibility in designing new functions. + For example, this is what Matthew Ghio had to to say about his remailer: - "Everything after the encrypted message gets passed along in the clear. If you don't want this, you can remove it using the cutmarks feature with my remailer. (Also, remail@extropia.wimsey.com doesn't append the text after the encrypted message.) The reason for this is that it allows anonymous replies. I can create a pgp message for a remailer which will be delivered to myself. I send you the PGP message, you append some text to it, and send it to the remailer. The remailer decrypts it and remails it to me, and I get your message. [M.G., alt.privacy.anon-server, 1994-07-03] 8.6.7. Remailer Sites - There is no central administrator of sites, of course, so a variety of tools are the best ways to develop one's own list of sites. (Many of us, I suspect, simply settle on a dozen or so of our favorites. This will change as hundreds of remailers appear; of course, various scripting programs will be used to generate the trajectories, handled the nested encryption, etc.) - The newsgroups alt.privacy.anon-server, alt.security.pgp, etc. often report on the latest sites, tools, etc. + Software for Remailers + Software to run a remailer site can be found at: - soda.csua.berkeley.edu in /pub/cypherpunks/remailer/ - chaos.bsu.edu in /pub/cypherpunks/remailer/ + Instructions for Using Remailers and Keyservers + on how to use keyservers - "If you have access to the World Wide Web, see this URL: http://draco.centerline.com:8080/~franl/pgp/pgp- keyservers.html" [Fran Litterio, alt.security.pgp, 1994- 09-02] + Identifying Remailer Sites + finger remailer-list@chaos.bsu.edu - returns a list of active remailers - for more complete information, keys, and instructions, finger remailer.help.all@chaos.bsu.edu - gopher://chaos.bsu.edu/ + Raph Levien has an impressive utility which pings the remailers and reports uptime: - finger remailer-list@kiwi.cs.berkeley.edu - or use the Web at http://www.cs.berkeley.edu/~raph/remailer-list.html - Raph Levien also has a remailer chaining script at ftp://kiwi.cs.berkeley.edu/pub/raph/premail-0.20.tar.gz + Remailer pinging - "I have written and installed a remailer pinging script which collects detailed information about remailer features and reliability. To use it, just finger remailer- list@kiwi.cs.berkeley.edu There is also a Web version of the same information, at: http://www.cs.berkeley.edu/~raph/remailer-list.html" [Raph Levien, 1994-08-29] + Sites which are down?? - tamsun.tamu.edu and tamaix.tamu.edu 8.6.8. "How do I set up a remailer at my site?" - This is not something for the casual user, but is certainly possible. - "Would someone be able to help me install the remailer scripts from the archives? I have no Unix experience and have *no* idea where to begin. I don't even know if root access is needed for these. Any help would be appreciated." [Robert Luscombe, 93-04-28] - Sameer Parekh, Matthew Ghio, Raph Levien have all written instructions.... 8.6.9. "How are most Cypherpunks remailers written, and with what tools?" - as scripts which manipulate the mail files, replacing headers, etc. - Perl, C, TCL - "The cypherpunks remailers have been written in Perl, which facilitates experimenting and testing of new interfaces. The idea might be to migrate them to C eventually for efficiency, but during this experimental phase we may want to try out new ideas, and it's easier to modify a Perl script than a C program." [Hal Finney, 93-01-09] - "I do appreciate the cypherpunks stuff, but perl is still not a very widely used standard tool, and not everyone of us want to learn the ins and outs of yet another language... So I do applaud the C version..." [Johan Helsingius, "Julf," 93-01-09] 8.6.10. Dealing with Remailer Abuse + The Hot Potato - a remailer who is being used very heavily, or suspects abuse, may choose to distribute his load to other remailers. Generally, he can instead of remailing to the next site, add sites of his own choosing. Thus, he can both reduce the spotlight on him and also increase cover traffic by scattering some percentage of his traffic to other sites (it never reduces his traffic, just lessens the focus on him). + Flooding attacks - denial of service attacks - like blowing whistles at sports events, to confuse the action - DC-Nets, disruption (disruptionf of DC-Nets by flooding is a very similar problem to disruption of remailers by mail bombs) + "How can remailers deal with abuse?" - Several remailer operators have shut down their remailers, either because they got tired of dealing with the problems, or because others ordered them to. - Source level blocking - Paid messages: at least this makes the abusers _pay_ and stops certain kinds of spamming/bombing attacks. - Disrupters are dealt with in anonymous ways in Chaum's DC- Net schemes; there may be a way to use this here. + Karl Kleinpaste was a pioneer (circa 1991-2) of remailers. He has become disenchanted: - "There are 3 sites out there which have my software: anon.penet.fi, tygra, and uiuc.edu. I have philosophical disagreement with the "universal reach" policy of anon.penet.fi (whose code is now a long-detached strain from the original software I gave Julf -- indeed, by now it may be a complete rewrite, I simply don't know); ....Very bluntly, having tried to run anon servers twice, and having had both go down due to actual legal difficulties, I don't trust people with them any more." [Karl_Kleinpaste@cs.cmu.edu, alt.privacy.anon-server, 1994-08-29] - see discussions in alt.privacy.anon-server for more on his legal problems with remailers, and why he shut his down 8.6.11. Generations of Remailers + First Generation Remailer Characteristics--Now (since 1992) - Perl scripts, simple processing of headers, crypto + Second Generation Remailer Characteristics--Maybe 1994 - digital postage of some form (perhaps simple coupons or "stamps") - more flexible handling of exceptions - mail objects can tell remailer what settings to use (delays, latency, etc.( + Third Generation Remailer Characteristics--1995-7? - protocol negotiation + Chaum-like "mix" characteristics - tamper-resistant modules (remailer software runs in a sealed environment, not visible to operator) + Fourth Generation Remailer Characteristics--1996-9? - Who knows? - Agent-based (Telescript?) - DC-Net-based 8.6.12. Remailer identity escrow + could have some uses... - what incentives would anyone have? - recipients could source-block any remailer that did not have some means of coping with serious abuse...a perfect free market solution - could also be mandated 8.6.13. Remailer Features + There are dozens of proposed variations, tricks, and methods which may or may not add to overall remailer security (entropy, confusion). These are often discussed on the list, one at a time. Some of them are: + Using one's self as a remailer node. Route traffic back through one's own system. - even if all other systems are compromised... - Random delays, over and above what is needed to meet reordering requirements - MIRVing, sending a packet out in multiple pieces - Encryption is of course a primary feature. + Digital postage. - Not so much a feature as an incentive/inducement to get more remailers and support them better. + "What are features of a remailer network?" - A vast number of features have been considered; some are derivative of other, more basic features (e.g., "random delays" is not a basic feature, but is one proposed way of achieving "reordering," which is what is really needed. And "reordering" is just the way to achieve "decorrelation" of incoming and outgoing messages). + The "Ideal Mix" is worth considering, just as the "ideal op amp" is studied by engineers, regardless of whether one can ever be built. - a black box that decorrelates incoming and outgoing packets to some level of diffusion - tamper-proof, in that outside world cannot see the internal process of decorrelation (Chaum envisioned tamper-resistant or tamper-responding circuits doing the decorrelation) + Features of Real-World Mixes: + Decorrelation of incoming and outgoing messages. This is the most basic feature of any mix or remailer: obscuring the relationship between any message entering the mix and any message leaving the mix. How this is achieve is what most of the features here are all about. - "Diffusion" is achieved by batching or delaying (danger: low-volume traffic defeats simple, fixed delays) - For example, in some time period, 20 messages enter a node. Then 20 or so (could be less, could be more...there is no reason not to add messages, or throw away some) messages leave. + Encryption should be supported, else the decorrelation is easily defeated by simple inspection of packets. - public key encryption, clearly, is preferred (else the keys are available outside) - forward encryption, using D-H approaches, is a useful idea to explore, with keys discarded after transmission....thus making subpoenas problematic (this has been used with secure phones, for example). + Quanitzed packet sizes. Obviously the size of a packet (e.g., 3137 bytes) is a strong cue as to message identity. Quantizing to a fixed size destroys this cue. + But since some messages may be small, and some large, a practical compromise is perhaps to quantize to one of several standards: - small messages, e.g., 5K - medium messages, e.g., 20K - large messages....handled somehow (perhaps split up, etc.) - More analysis is needed. + Reputation and Service - How long in business? - Logging policy? Are messages logged? - the expectation of operating as stated + The Basic Goals of Remailer Use + decorrelation of ingoing and outgoing messages - indistinguishability + "remailed messages have no hair" (apologies to the black hole fans out there) - no distinguishing charateristics that can be used to make correlations - no "memory" of previous appearance + this means message size padding to quantized sizes, typically - how many distinct sizes depends on a lot fo things, like traffic, the sizes of other messages, etc. + Encryption, of course - PGP - otherwise, messages are trivially distinguishable + Quantization or Padding: Messages - padded to standard sizes, or dithered in size to obscure oringinal size. For example, 2K for typical short messages, 5K for typical Usenet articles, and 20K for long articles. (Messages much longer are hard to hide in a sea of much shorter messages, but other possibilities exist: delaying the long messages until N other long messages have been accumulated, splitting the messages into smaller chunks, etc.) + "What are the quanta for remailers? That is, what are the preferred packet sizes for remailed messages?" - In the short term, now, the remailed packet sizes are pretty much what they started out to be, e.g, 3-6KB or so. Some remailers can pad to quantized levels, e.g., to 5K or 10K or more. The levels have not been settled on. - In the long term, I suspect much smaller packets will be selected. Perhaps at the granularity of ATM packets. "ATM Remailers" are likely to be coming. (This changes the nature of traffic analyis a bit, as the _number_ of remailed packets increases. - A dissenting argument: ATM networks don't give sender the control over packets... - Whatever, I think packets will get smaller, not larger. Interesting issues. - "Based on Hal's numbers, I would suggest a reasonable quantization for message sizes be a short set of geometrically increasing values, namely, 1K, 4K, 16K, 64K. In retrospect, this seems like the obvious quantization, and not arithmetic progressions." [Eric Hughes, 1994-08-29] - (Eudora chokes at 32K, and so splits messages at about 25K, to leave room for comments without further splitting. Such practical considerations may be important to consider.) + Return Mail - A complicated issue. May have no simple solution. + Approaches: - Post encrypted message to a pool. Sender (who provided the key to use) is able to retrieve anonymously by the nature of pools and/or public posting. + Return envelopes, using some kind of procedure to ensure anonymity. Since software is by nature never secure (can always be taken apart), the issues are complicated. The security may be gotten by arranging with the remailers in the return path to do certain things to certain messages. - sender sends instructions to remailers on how to treat messages of certain types - the recipient who is replying cannot deduce the identity, because he has no access to the instructions the remailers have. - Think of this as Alice sending to Bob sending to Charles....sending to Zeke. Zeke sends a reply back to Yancy, who has instructions to send this back to Xavier, and so on back up the chain. Only if Bob, Charles, ..., Yancy collude, can the mapping in the reverse direction be deduced. - Are these schemes complicated? Yes. But so are lot of other protocols, such as getting fonts from a screen to a laser printer + Reordering of Messages is Crucial + latency or fanout in remailers + much more important than "delay" - do some calculations! + the canard about "latency" or delay keeps coming up - a "delay" of X is neither necessary nor sufficient to achieve reordering (think about it) - essential for removing time correlation information, for removing a "distinguishing mark" ("ideal remailed messages have no hair") + The importance of pay as you go, digital postage + standard market issues - markets are how scarece resources are allocated - reduces spamming, overloading, bombing - congestion pricing - incentives for improvement + feedback mechanisms - in the same way the restaurants see impacts quickly - applies to other crypto uses besides remailers + Miscellaneous - by having one's own nodes, further ensures security (true, the conspiring of all other nodes can cause traceability, but such a conspiracy is costly and would be revealed) + the "public posting" idea is very attractive: at no point does the last node know who the next node will be...all he knows is a public key for that node + so how does the next node in line get the message, short of reading all messages? - first, security is not much compromised by sorting the public postings by some kind of order set by the header (e.g., "Fred" is shorthand for some long P-K, and hence the recipient knows to look in the Fs...obviously he reads more than just the Fs) + outgoing messages can be "broadcast" (sent to many nodes, either by a literal broadcast or public posting, or by randomly picking many nodes) - this "blackboard" system means no point to point communication is needed + Timed-release strategies + encrypt and then release the key later - "innocuously" (how?) - through a remailing service - DC-Net - via an escrow service or a lawyer (but can the lawyer get into hot water for releasing the key to controversial data?) - with a series of such releases, the key can be "diffused" - some companies may specialize in timed-release, such as by offering a P-K with the private key to be released some time later - in an ecology of cryptoid entities, this will increase the degrees of freedom + this reduces the legal liability of retransmitters...they can accurately claim that they were only passing data, that there was no way they could know the content of the packets - of course they can already claim this, due to the encrypted nature + One-Shot Remailers - "You can get an anonymous address from mg5n+getid@andrew.cmu.edu. Each time you request an anon address, you get a different one. You can get as many as you like. The addresses don't expire, however, so maybe it's not the ideal 'one-shot' system, but it allows replies without connecting you to your 'real name/address' or to any of your other posts/nyms." [ Matthew Ghio, 1994-04-07] 8.6.14. Things Needed in Remailers + return receipts - Rick Busdiecker notes that "The idea of a Return-Receipt- To: field has been around for a while, but the semantics have never been pinned down. Some mailer daemons generate replies meaning that the bits were delivered." [R.B., 1994-08-08] + special handling instructions - agents, daemons - negotiated procedures + digital postage - of paramount importance! - solves many problems, and incentivizes remailers + padding + padding to fixed sizes - padding to fixed powers of 2 would increase the average message size by about a third - lots of remailers - multiple jursidictions - robustness and consistency + running in secure hardware - no logs - no monitoring by operator - wipe of all temp files - instantiated quickly, fluidly - better randomization of remailers 8.6.15. Miscellaneous Aspects of Remailers + "How many remailer nodes are actually needed?" - We strive to get as many as possible, to distribute the process to many jurisdictions and with many opeators. - Curiously, as much theoretical diffusivity can occur with a single remailer (taking in a hundred messages and sending out a hundred, for example) as with many remailers. Our intuition is, I think, that many remailers offer better diffusivity and better hiding. Why this is so (if it is) needs more careful thinking than I've seen done so far. - At a meta-level, we think multiple remailers lessens the chance of them being compromised (this, however, is not directly related to the diffusivity of a remailer network- -important, but not directly related). - (By the way, a kind of sneaky idea is to try to always declare one's self to be a remailer. If messages were somehow traced back to one's own machine, one could claim: 'Yes, I'm a remailer." In principle, one could be the only remailer in the universe and still have high enough diffusion and confusion. In practice, being the only remailer would be pretty dangerous.) + Diffusion and confusion in remailer networks + Consider a single node, with a message entering, and two messages leaving; this is essentially the smallest "remailer op" - From a proof point of view, either outgoing message could be the one - and yet neither one can be proved to be - Now imagine those two messages being sent through 10 remailers...no additional confusion is added...why? - So, with 10 messages gong into a chain of 10 remailers, if 10 leave... - The practical effect of N remailers is to ensure that compromise of some fraction of them doesn't destroy overall security + "What do remailers do with misaddressed mail?" - Depends on the site. Some operators send notes back (which itself causes concern), some just discard defective mail. This is a fluid area. At least one remailer (wimsey) can post error messages to a message pool--this idea can be generalized to provide "delivery receipts" and other feedback. - Ideal mixes, a la Chaum, would presumably discard improperly-formed mail, although agents might exist to prescreen mail (not mandatory agents, of course, but voluntarily-selected agents) - As in so many areas, legislation is not needed, just announcement of policies, choice by customers, and the reputation of the remailer. - A good reason to have robust generation of mail on one's own machine, so as to minimize such problems. + "Can the NSA monitor remailers? Have they?" + Certainly they _can_ in various ways, either by directly monitoring Net traffic or indirectly. Whether they _do_ is unknown. - There have been several rumors or forgeries claiming that NSA is routinely linking anonymous IDs to real IDs at the penet remailer. + Cypherpunks remailers are, if used properly, more secure in key ways: - many of them - not used for persistent, assigned IDs - support for encryption: incoming and outgoing messages look completely unlike - batching, padding, etc. supported - And properly run remailers will obscure/diffuse the connection between incoming and outgoing messages--the main point of a remailer! + The use of message pools to report remailer errors - A good example of how message pools can be used to anonymously report things. - "The wimsey remailer has an ingenious method of returning error messages anonymously. Specify a subject in the message sent to wimsey that will be meaningful to you, but won't identify you (like a set of random letters). This subject does not appear in the remailed message. Then subscribe to the mailing list errors-request@extropia.wimsey.com by sending a message with Subject: subscribe. You will receive a msg for ALL errors detected in incoming messages and ALL bounced messages." [anonymous, 93-08-23] - This is of course like reading a classified ad with some cryptic message meaningful to you alone. And more importantly, untraceable to you. + there may be role for different types of remailers - those that support encryption, those that don't + as many in non-U.S. countries as possible - especially for the *last* hop, to avoid subpoena issues - first-class remailers which remail to *any* address + remailers which only remail to *other remailers* - useful for the timid, for those with limited support, etc. - + "Should mail faking be used as part of the remailer strategy?" - "1. If you fake mail by talking SMTP directly, the IP address or domain name of the site making the outgoing connection will appear in a Received field in the header somewhere." "2. Fake mail by devious means is generally frowned upon. There's no need to take a back-door approach here--it's bad politically, as in Internet politics." [Eric Hughes, 94-01-31] - And if mail can really be consistently and robustly faked, there would be less need for remailers, right? (Actually, still a need, as traffic analysis would likely break any "Port 25" faking scheme.) - Furthermore, such a strategy would not likely to be robust over time, as it relies on exploiting transitory flaws and vendor specifics. A bad idea all around. + Difficulties in getting anonymous remailer networks widely deployed - "The tricky part is finding a way to preserve anonymity where the majority of sites on the Internet continue to log traffic carefully, refuse to install new software (especially anon-positive software), and are administrated by people with simplistic and outdated ideas about identity and punishment. " [Greg Broiles, 1994-08-08] + Remailer challenge: insulating the last leg on a chain from prosecution + Strategy 1: Get them declared to be common carriers, like the phone company or a mail delivery service + e.g., we don't prosecute an actual package deliveryperson, or even the company they work for, for delivery of an illegal package - contents assumed to be unknown to the carrier - (I've heard claims that only carriers who make other agreements to cooperate with law enforcement can be treated as common carriers.) + Strategy 2: Message pools + ftp sites - with plans for users to "subscribe to" all new messages (thus, monitoring agencies cannot know which, if any, messages are being sought) - this gets around the complaint about too much volume on the Usenet (text messages are a tiny fraction of other traffic, especially images, so the complaint is only one of potentiality) + Strategy 3: Offshore remailers as last leg - probably set by sender, who presumably knows the destination - A large number of "secondary remailers" who agree to remail a limited number... + "Are we just playing around with remailers and such?" - It pains me to say this, but, yes, we are just basically playing around here! - Remailer traffic is so low, padding is so haphazard, that making correlations between inputs and outputs is not cryptographically hard to do. (It might _seem_ hard, with paper and pencil sorts of calculations, but it'll be child's play for the Crays at the Fort.) - Even if this is not so for any particular message, maintaining a persistent ID--such as Pr0duct Cypher does, with digital sigs--without eventually providing enough clues will be almost impossible. At this time. - Things will get better. Better and more detailed "cryptanalysis of remailer chains" is sorely needed. Until then, we are indeed just playing. (Play can be useful, though.) + The "don't give em any hints" principle (for remailers) - avoid giving any information - dont't say which nodes are sources and which are sinks; let attackers assume everyone is a remailer, a source - don't say how long a password is - don't say how many rounds are in a tit-for-tat tournament
Next Page: 8.7 Anonymous Posting to Usenet
Previous Page: 8.5 Untraceable E-Mail
By Tim May, see README
HTML by Jonathan Rochkind