Remailer ideas (Was: Re: Latency vs. Reordering)

The first one could probably be done- if someone (grin- if I find
any time soon, this is a project I'd like to do) wrote a nice
package that was easy to install and use with a feature set that
could be agreeable to most.
The second one is the problem, but could be dealt with by the
first by establishing automated communication- when someone
installs the package, send a control message another remailer
already part of the web which 'registers' it, and then the web
consistently tries to maintain itself by checking on the others
and dropping ones that go down off the list. Some sort of method
would have to be found for ones that drop off then later come
online again so that control messages didn't have to be manually
initiated every time, but that shouldn't be that hard.
What are the problems in the above?
Would Perl be a good choice for doing this?
I saw some code from a remailer some time ago, but lost my mailbox
a while back (which could also mena that this is a dry rehash of
an old discussion... apologies if I am rewriting someone elses
thoughts). Anyone still have this?
Am I talking out my ass?
-j
--
"Blah Blah Blah"
___________________________________________________________________
Jamie Lawrence <jamiel@sybase.com>

Date: Thu, 28 Jul 1994 11:37:38 -0800
   From: jamiel@sybase.com (Jamie Lawrence)

   Another thing that occured to me is the thought that if there were
   an organized web or remailers, remailers could bounce messages
   between them automatically-

Yes, that could be done.  Problem is that the NSA's remailer(s) would
immediately deliver messages to the destination.  Get enough NSA
remailers, and the web wouldn't be trustable.  Now, remailers in the
web can and should feel free to randomly forward mail to other
remailers, but it's the sender who should pick the minimum chain
length, and recursively encrypt their own envelopes.

-russ <nelson@crynwr.com>    http://www.crynwr.com/crynwr/nelson.html
Crynwr Software   | Crynwr Software sells packet driver support | ask4 PGP key
11 Grant St.      | +1 315 268 1925 (9201 FAX)  | What is thee doing about it?
Potsdam, NY 13676 | LPF member - ask me about the harm software patents do.

jamiel@sybase.com (Jamie Lawrence) writes:

>I was thinking some about remailers and means to create more
>effective ones. I think the idea of padding messages has been
>kicked around (has anyone implemented it?), but what about random
>compression? Some messages are compressed, others are padded, some
>are left alone, perhaps shooting for a median message size
>(everything coming from this mailer tries to be 9k, or as close as
>possible). Of course, this requires a standard so that other
>remailers downstream can make the message readable.

The real problem to be solved is this: given a set of input messages,
and a set of output messages which represent decryptions of the input
ones (along with perhaps a bit of extra processing), make it impossible
to tell which output messages go with which input ones.  Clearly, if the
messages are of widely disparate sizes, and output messages are similar
size to input messages, that won't do.  That is where the idea of padding,
and of standardized messages sizes, comes from.

Hal