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

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

-----BEGIN PGP SIGNED MESSAGE-----

In article <199407282120.RAA07884@cs.oberlin.edu> you write:
>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.]

I thought extra useless junk traffic was one main objective of a
remailing network?   The more the better..  As far as the idea
that an eavesdropper could tell which remailers you are going to
use - they already know.  They can ping the same sites you do
and as long as you ping *every* site you know of, instead of
just the ones you'd like to use on any given message, this
doesn't give the spooks one iota of new information.

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

As long as the key isn't trusted just because it was in the
newsgroup - this sounds workable.  Or, each remailer could have
a mailing list of addresses it sends the "i'm here" message to. 
Again, this gets the spooks no new information - if you use a
remailer even once, you have to assume that if some one was
watching closely enough, they *know* you used the system, and
they *know* your chosen destination received a message from the
system.  They just can't figure out who sent what to who.

>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

This seems backwards to me - I think what you want is local
software that is smart enough to figure out the state of the
remailer-net.  You needn't rip apart nor rebuild the whole net,
just write some code :)

- --
 Baba baby mama shaggy papa baba bro baba rock a shaggy baba sister
shag saggy hey doc baba baby shaggy hey baba can you dig it baba baba
        E7 E3 90 7E 16 2E F3 45   *   28 24 2E C6 03 02 37 5C 
   Stuart Smith                           <stu@nemesis.wimsey.com>

-----BEGIN PGP SIGNATURE-----
Version: 2.6

iQCVAgUBLkACeai5iP4JtEWBAQHmFAQApaJMGuDPGHCtEBcfFV6kfGNAwx0fuTgO
jQ8yp10UHbe8ItfmjTZBFdHY4zfnPFIL6htn+6gcmOygj6OFEu320r+hA4u3Q7s/
opSaL72kAM53MQOHLabnZ80eEWQts3PWE1i4SfuGomkHKi5BZOUA5HwC+5DF4zTk
7RkW5E7f7a8=
=xUgv
-----END PGP SIGNATURE-----

Re putting remailer aliveness on usenet:

What I think is a better idea was proposed here last year, and I think
someone was doing it for a while.  It is for someone to volunteer to
be the keeper of the remailer aliveness information.  He runs scripts
every day to ping the remailers, keeps lists of which remailers are
currently active, and so on.  This information is collected and put into
a file retrievable by email or finger.  This way you need only check a
single site to find out which remailers are up, and you don't have the
usenet waste of sending stuff all over the world that only a few people
are interested in (yes, I know usenet does this already, but it won't
forever).

Just like people set up web sites that point to interesting resources,
some people will (and perhaps are already) run sites which point to good
remailers.  This is just as useful a service as running a remailer, and
a good deal less controversial.  This seems like a good solution to the
problem of finding running remailers.

Hal

Hal Finney writes:


> What I think is a better idea was proposed here last year, and I think
> someone was doing it for a while.  It is for someone to volunteer to
> be the keeper of the remailer aliveness information.  He runs scripts
> every day to ping the remailers, keeps lists of which remailers are
> currently active, and so on.  This information is collected and put into
> a file retrievable by email or finger.  This way you need only check a

Matthew Ghio was doing this for a while, and posted about it here
several times.

I told him I'd "subscribe to" a robust, stable, pinging service, one
that offered a table of various things, including:

- time in operation (important for deciding to use it or not)

- successful remails out of last N (e.g., "32 of last 34 attempts were
valid")

- maybe a _recent_ result (e.g., "5 out of 5 in last 24 hours were
valid")

- remailer policy, including encryption, logging, etc.

I still intend to pay Matthew once I get back to using such remailers
(I haven't in a long while) and can confirm that Matthew is indeed
offering a stable, robust, useful service. I doubt he'll maintain it
just for me, so maybe others of you can help. (I hate donation-based
systems, so clearly a true "subscription finger" or "subscription ftp"
would be better...and maybe fairly easy to implement, too.)

--Tim May



-- 
..........................................................................
Timothy C. May         | Crypto Anarchy: encryption, digital money,  
tcmay@netcom.com       | anonymous networks, digital pseudonyms, zero
408-688-5409           | knowledge, reputations, information markets, 
W.A.S.T.E.: Aptos, CA  | black markets, collapse of governments.
Higher Power: 2^859433 | Public Key: PGP and MailSafe available.
"National borders are just speed bumps on the information superhighway."

remail@c2.org and remailer@soda.csua.berkeley.edu both run such things
accessible via finger. Unfortunately there is a bug in the code
(written by Ray Cromwell.. not to place blame on him but to give him
credit) which does it that clobbers the list of remailers to ping and
I haven't gotten around to writing a backup mechanism so the list of
active remailers isn't killed whenever the bug happens. (Yes, the bug
*should* be fixed at the source..)

	If people could send their personal lists of remailers to
sameer@c2.org and datura@leri.org (he's working on a remailer client)
with the keys for these remailers, that *Would* be appreciated.

> 
> Re putting remailer aliveness on usenet:
> 
> What I think is a better idea was proposed here last year, and I think
> someone was doing it for a while.  It is for someone to volunteer to
> be the keeper of the remailer aliveness information.  He runs scripts
> every day to ping the remailers, keeps lists of which remailers are
> currently active, and so on.  This information is collected and put into
> a file retrievable by email or finger.  This way you need only check a
> single site to find out which remailers are up, and you don't have the
> usenet waste of sending stuff all over the world that only a few people
> are interested in (yes, I know usenet does this already, but it won't
> forever).
> 
> Just like people set up web sites that point to interesting resources,
> some people will (and perhaps are already) run sites which point to good
> remailers.  This is just as useful a service as running a remailer, and
> a good deal less controversial.  This seems like a good solution to the
> problem of finding running remailers.
> 
> Hal
> 


-- 
sameer						Voice:   510-841-2014
Network Administrator				Pager:	 510-321-1014
Community ConneXion: The NEXUS-Berkeley		Dialin:  510-841-0909
http://www.c2.org (or login as "guest")			sameer@c2.org