Totally Anonymous Remailing

Just toying around with some ideas, and came up with this:

Totally Anonymous Remailing (V1.0)

An "TAR" goes active on the net at site anon.com.
It publishes a Public Key.

1) Creating an anonymous ID.

A User sends message to create-id@anon.com, encrypted with the TAR's
Public key.  The message contains four elements:

	A Public Key generated by the User.
	A Proposed Pseudonym (ie: "Artful-Dodger")
	The Proposed Pseudonym encrypted by the User's Private Key.
	
At this point, the TAR can verify that the new user isn't spoofing
by giving someone else's public key.  It does not reply to the
email message, nor does it store the source (which in any case
could be another anonymous remailer).  If the new Pseudo isn't in
use, it gets allocated.  If it is, it does not.

2) Sending mail to an anonymous ID

Works the same as sending mail to anyone else.  However, on receipt
it is immediately encrypted with the recipients Public key and
placed in a Mail queue.  It is _not_ automatically forwarded.

3) Using an anonymous ID.

The User sends a message to use-id@anon.com, encrypted with the
TAR's Public key.  The message contains the following:

	The User's Pseudonym (ie: "Artful-Dodger@anon.com")
	Command
	Command Specific Parameters

The Command and Parameters are encrypted with the User's private
Key.  This has several nice features that will become apparent
later.

If the command contains errors, or does not decrypt properly, the
anon mailer places an error message into the Pseudonym's mail
queue, but does not otherwise reply.

Commands would be typical:

	MAIL <username(s)>
	{ CC <username(s)>}
	{ BCC <username(s)>}
	{ SUBJECT <whatever>}
	<message>

		Sends <message> using psuedonym.  <messages>
		ought to be encrypted.

	POST <newsgroups(s)>
	SUBJECT <whatever>
	<message>

		Posts <message> using psuedonym.  You could
		verify your pseudo was accepted by posting
		to a worldwide test group.

	SEND <destination>

		Sends accumulated mail, in a batch, to the
		email address specified.  So you can log on
		to any account, even a guest, and get your
		mail.

and so on.  Might be nice to make it a shell on top of something
like MH, and allow you to manage your mailbox remotely and
anonymously.

BTW, none of this double-blind crap.  If someone wants to
reply anonymously, they ought to create their own pseudo.

Anon-net:

Note that use-id@ has a nice property.  Assume there is another
anon server, noname.com, which gets a message, encrypted with
it's public key, that is a command for Artful-Dodger@anon.com.
It can simply re-encrypt the message with anon.com's public key
and pass it on, never having seen the command because it is
encrypted - and only anon.com knows Artful-Dodger's public key,
because Artful only sent it to anon once, encrypted with anon's
key.  The extension - several anon sites passing mail back and
forth regularly (all encrypted batches containing several real
and fake messages) - is obvious and makes traffic analysis
more difficult (especially as the number of sites goes up).

There could also be a facility for one-shot "bounces," the
ability to use the anon site to bounce an email to a restricted
number of addresses (typically, other anon sites).  So you could
email to noname (using noname's key) and have the message bounced
to anon.  So you could have an account on anon and yet never
directly send email to anon -- it would never at any time have
any clue as to your identity.

Of course, you'd have to trust the software.  And some work needs
to be done to ensure the net stays viable even if some of the
sites have been subverted.

This is only a first draft, probably many mistakes.
Comments?

> From: Robert J Woodhead <trebor@foretune.co.jp>

> Just toying around with some ideas, and came up with this:
> 
> Totally Anonymous Remailing (V1.0)
[...]
> 	SEND <destination>
> 
> 		Sends accumulated mail, in a batch, to the
> 		email address specified.  So you can log on
> 		to any account, even a guest, and get your
> 		mail.

A problem here.  The SEND system eliminates the risk of database
seizure, and encrypting mail to the remailer eliminates snooping on
incoming mail, but outgoing mail is unprotected.  Anybody watching
net traffic coming out of the TAR can snoop the destination of SEND
requests, and reasonably presume that address to be the owner of the
nym.  This is of course a problem with a penet-style setup too, but
it's something to fix if you want to be "totally anonymous".  

I fairly recently posted a scheme by which a remailer could reduce
this hazard, while retaining the same front end -- which may or may
not be a wise move.  I hesitate to blat the thing to the list again,
but the plan was to use cypherpunks remailers as a back-end delivery
mechanism.  With a given key the nymserver would associate a
pseudonym and a list of delivery points, of which the first living
one would be used.  These could be either normal addresses (backward-
compatible idiot mode), or remailer addresses associated with
(encrypted!) addressing blocks to prepend.  

One thing I didn't address, which needs to be, is how best to handle
testing of the delivery chains.  I think this is a make-or-break
issue for the general usability of this thing.

   Eli   ebrandt@jarthur.claremont.edu

Eli writes regarding my Totally Anonymous Mailing scheme:
>A problem here.  The SEND system eliminates the risk of database
>seizure, and encrypting mail to the remailer eliminates snooping on
>incoming mail, but outgoing mail is unprotected.  Anybody watching
>net traffic coming out of the TAR can snoop the destination of SEND
>requests, and reasonably presume that address to be the owner of the
>nym.  This is of course a problem with a penet-style setup too, but
>it's something to fix if you want to be "totally anonymous".  

I don't think this is a problem.  The send command is received by
the mailing system encrypted by the mailer's public key.  An outside
observer can't decode the message.  When it gets the message, the
mailer decrypts the envelope, and gets the sender's pseudonym and
an encrypted command (encrypted with the sender's private key).
The mailer knows the pseudo's public key, so it can decrypt the
command.  If it is a spoofed command, the mailer gets junk, and
merely sends email into the psuedo's account giving details of
the intrusion attempt (which might just be an error on the
owner's part).

The outgoing mail packet(s) would be encrypted by the pseudo owner's
public key, so only he could read them.

Some mechanism might have to be added to prevent an irritating "spoof"
attack where the attacker records an incoming message and merely
duplicates it.  This might involve having the server remember the last
couple of weeks of command transactions, reject duplicates, and
reject any messages more than a week "old."  This would require a
timestamp in the encrypted part of the message.

The part of the proposal that really needs work is methods to make
traffic analysis prohibitive.  I suspect that a net of cooperative
mailers, along with the ability to delay the relay of outgoing mail,
might help in that regard.