My pseudo-anonymous dream list
-----BEGIN PGP SIGNED MESSAGE----- There was some talk on Friday about "nym" servers similar in operation to anon.penet.fi. I was meaning to provide some commentary on Friday, but it kinda got pushed back by a lazy weekend. Anyways, I wanted to toss some non-technical things into the fray about what I'd like to see in a good "nym" server. If you grow weary from my wish-rants, press 'd' now :-) ============== Anon.penet.fi is arguably one of the most used anonymous servers on the Internet. One of the chief reasons it is used so much by so many so often is because it is also the easiest to use. Posting to a newsgroup or mailing to another person is handled without having to think about anything. This is quite unlike most anonymous remailers which require quite a bit more work (for the lay person) for only one-way mailing. Any future remailers (and for the purpose of this message, assume "remailer" means a pseudo-anonymous remailing mechanism like penet.fi) will need to maintain the ease of use that penet.fi has. No messy headers of embedded command lines. Just send the message to an address and it's taken care of. There are, however, a great number of internal improvements that could be made that would both improve user-end usefulness AND improve overall security. 1) Multiple Remailers: I'd like to see multiple (maybe >12) remailers that utilize the same database, upgraded by batched processes once or twice a day or "broadcast" realtime to all the reamilers in the web (probably the latter is better). In this way, a person with a pseudo-ID of FOO, could be addressed as FOO at ANY of the remailers. The primary purpose of this is to allow easy chaining (see below), but it might also serve to distribute much of the load around the net. Penet.fi is grossly overloaded, so a solution to that needs to be found. 2) Encrypted Databases: One of the failings of anon.penet.fi that has been exploited by by various LEAs is the fact that the database of users is accessible by the operator. Any properly designed 'nym' server should have a totally encrypted database. Thus if your local LEA roams by demanding to know the name of the person associated with an ID, the best the operator can do is to give them a copy of the encrypted entry from the database (or, I suppose, the entire database :-) 3) Limited ID lifetime Another failing, IMHO, with penet.fi is that ID#'s have an unlimited lifetime. I think any remailer should limit the lifetime of any ID to no longer than 12 months, with six months being the default, and 3 months being an option (plus, of course, a manual cancelation on the part of the user). When an ID is expired, it is removed entirely from the database and NOT reissued again. 4) Chained Mailings Because you have many remailers operating, all messages should be randomly chained through them. Perhaps the default number of hops is three, with the user-definable of 1 to 20. This means that while I might send a message to alt.sex.abuse.recovery@anon.mit.edu, it might end up being posted from anon.berkeley.edu after passing through anon.umn.edu and anon.toad.com. It makes traffic analysis that much more difficult. Before a chaining is done, the remailer should ping the target remailer to make sure it is up, so that mail isn't sitting in the queue. All chained mail should also be encrypted. 5) Encryption/Signature Validation Any message that is emailed PGP signed should be validated by the remailer (with the User having to email in their public key as part of the registration process, if they so choose, or remailers can use the keyserver). If the signature is valid, a line is added in remailer information section to the effect of "Message PGP Validated" and then sent PGP signed by the remailer. (the original sender's PGP signature is removed). An encrypted message should simply be PGP Signed by the final remailer posted/emailed to the destination Because there are multiple remailers (chained), only the final remailer should sign the message. 6) Two-way This goes pretty much without saying. If I send mail to somebody or post to news through a remailer, the person who received the message should be able to reply to my anonymous mailbox and I get the message (signed, of course, by the remailer). 7) Option Validation In order to change any of the options on your ID (ie, the expiration date of your ID, or to expire it immediately, or to set the number of "hops" you want to chain through), you should have to submit a PGP Signed command message. Then, similar to a LISTSERV that confirms subscriptions and unsubscriptions, a message is sent back asking you to "ok" these changes. This return message is sent as PGP encrypted email to your public key. When you decode it, you are given a, say, 10digit code string that you need to mail back to confirm the changes. If you don't, it doesn't. This helps keep down spoofing of messages changing your options without your ok. It's not perfect, and isn't totally secure, but it will catch many. In addition, you encourage the use of PGP by requiring it for changing any options. You can still use the remailer without PGP, but you can't access the options and are stuck with the defaults. However, one item that should not be allowed to be changed is your email address. If you move from foo@blah.com to blah@foo.com, you need to get a new ID, and expire the old one (or it will die by itself within a year). 8) Robust Web of Remailers Remailers come and go daily. Any pseudo-anonymous remailer web needs to be able to handle that fact. Thus, a mechanism needs to be put into place to allow for easy adding of a new machine (if it's easy, more people will do it) with minimal maintanence. In addition, if a remailer disappears (say, because somebody caught wind of it and ordered the student to turn it off :-), the rest of the remailer web needs to be able to survive. Of course, that particular address will be dead, but with apprpriate FAQs posted around, people should be able to quickly find another address that uses the same database. 9) Proper PR This beeds to be properly advertised as well. Penet.fi, whether good or bad, has a reputation of being a breeding ground for law-breakers. Any web set up needs to be pushed as nothing more than a "P.O. Box" on the Internet or some such. In reality, nothing is different, but in the public light, it would work better. 10) There is no number 10 ===================== Hmm, guess that's about it. Comments are appreciated (really they are :-) -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: PGP Signed with PineSign 2.2 iQCVAwUBMC6dmTokqlyVGmCFAQFrdAP/c/tWh9EtobXW4mTWKaWf7B+uaLJjQ/fW UwTkJKIsZYsoj3fzeTMN4lLNd0x2sIJdB+uCduTCm6UFPzlYVa9GKk2TmO+odtvd 4sCjqnYb0JDmxSWO2lC6OW6GiswTabpCbJ/tq4eSMHXZkM/UYfN3HQjupDQ7nPny VpxcAlNHueQ= =IUA6 -----END PGP SIGNATURE----- ____ Robert A. Hayden <=> hayden@krypton.mankato.msus.edu \ /__ Finger for Geek Code Info <=> Finger for PGP Public Key \/ / -=-=-=-=-=- -=-=-=-=-=- \/ http://krypton.mankato.msus.edu/~hayden/Welcome.html -----BEGIN GEEK CODE BLOCK----- Version: 3.0 GED/J d-- s:++>: a-- C++(++++) ULU++ P+! L++ E---- W+(-) N++++ K+++ w--- O- M+ V-- PS++>$ PE++>$ Y++ PGP++ t- 5+++ X++ R+++>$ tv+ b+ DI+++ D+++ G++++>$ e++ h r-- y++** ------END GEEK CODE BLOCK------
participants (1)
-
Robert A. Hayden