From: Jonathan Rochkind <jrochkin@cs.oberlin.edu>
Date: Thu, 28 Jul 94 14:20:58 PDT
To: cypherpunks@toad.com
Subject: Re: Remailer ideas (Was: Re: Latency vs. Reordering)
Message-ID: <199407282120.RAA07884@cs.oberlin.edu>
MIME-Version: 1.0
Content-Type: text/plain


> 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.

Very good point. Still, I wish there was a way for my local software to     
automatically make this chain based on some sort of knowledge of what
remailers are currently up. Ideally, my local software could figure
out all this info without manual intervention on my part; it would maintain
it's own list of remailers, and keep track of when they go down.
I'm not sure it's possible to set up a system like this, but it
would be enormously helpful.
 
One naive solution would be for remailers to have a "ping" function. I could
send a remailer a "ping" message, and it would just bounce some acknowledgement
back. More likely, my software could do this periodically, and keep track
of which remailers are down, or non existent, and not use those. 
The problem here is that an eavesdropper could get knowledge of which remailers
I am planning on using, which could help traffic analysis enormously. 
The "ping" function could support anon encryption block, so that I can
ping a remailer through several other remailers anonymously. This is an
improvement, but the traffic generated by lots of people periodically doing
this is going to be enormous. As it is in any implementation of this sort. 
[If you wanted to, you could make the remailers "ping" now by yourslef, just 
have a message resent to yourself. But we can't all do this automatically often,
simply because of the traffic it woudl generate. I think.]
 
The next idea I had involves a usenet newsgroup. Bear in mind I don't really
know how this sort of thing works, so tell me when I've said something    
nit-witted. Anyhow, there could be an alt.remailer.net newsgroup. 
All participating remailers would post an "i'm here" message on it
periodically, say once every 24 hours. This message would include the 
remailers public key as well. My local software could scan this newsgroup.
If a remailer hadn't posted a "i'm here" message in 30 hours or so, my
local software wouldn't include it in any chains. If it's been several
weeks, my local software will drop it from my database of remailer's
altogether. If a "i'm here" from a previously unknown remailer is found,
my software adds it to the database. Or, if I'm worried about abuse, I only
add it to the database if it's public key is singed by someone I trust.  
 
Okay, now everyone try to rip this plan apart. :) I'm sure I haven't arrived
at the idea solution, but there's got to be some way to create a remailer-net
that will allow my local software to generate long remailer chains to remailers
that are all still existent (now, if one of the remailers included in my
6 remailer chain goes down, it's a major pain to figure out which one it was,
and why my mail never arrived there), all automatically. Until we can  
arrive at such a system, remailers are never going to be really useful
to a large number of people; it's just too generate secure remaielr    
^?chains that are trustable.