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
By Tim May, see README
HTML by Jonathan Rochkind