[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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 [email protected], 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 [email protected] to [email protected], 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 <=> [email protected]
\ /__ 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------