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.
participants (3)
-
Eli Brandt -
Robert J Woodhead -
Robert J. Woodhead