Re: REMAIL: Cover traffic

Hal writes:

> Several people have suggested that the remailers could send bogus
> messages amongst themselves in order to allow more "confusion and
> diffusion" of the other messages passing through the remailer network.
> The remailers could then batch up incoming messages fairly frequently
> and still have many messages in a batch.
> 

> The problem with this that I see is that, looking at the remailer
> network as a whole, you still may have one message in and one message
> out a short while later.  The fact that it was temporarily mixed up
> with a bunch of other messages doesn't help much if this message is the
> only one to leave the network.  If the Opponent has the ability to
> monitor all traffic into and out of all nodes of the network (as he
> would have to do anyway to defeat remailers even without this cover
> traffic) then he will easily be able to find the messages which are not
> aimed at other remailers.
> 


How about extending the "send bogus messages" idea all the way out to the  
users of the remailer system?  Part of the price of using the remailer  
system is that you will occasionally receive a bogus message.

How might this work?

Assume remailers know the addresses of all (or most) of the other  
remailers.  In other words, assume a given remailers knows if an inbound  
message came from another remailer, or came from a non-remailer address.

All inbound messages to a remailer from a non-remailer address would be  
considered a "use" of that remailer.  A remailer would maintain a list of  
the addresses of "users" and would occasionally send bogus messages to a  
randomly selected entry from its user list.  Inclusion into the list would  
be automatic.  The list would be a large, but fixed sized FIFO, with old  
entries dropping off the end automatically.

If the remailer system uses Digital Postage, then perhaps the bogus  
message could be a token for a free Digital Stamp, good for one message.

I'm sure many will object to tracking the users of a remailer, but I don't  
see how tracking can be prevented, other than by mutual agreement.  Can we  
use tracking to *increase* privacy?

Jim_Miller@suite.com

Jim Miller writes,

> How about extending the "send bogus messages" idea all the way out to the  
> users of the remailer system?  Part of the price of using the remailer  
> system is that you will occasionally receive a bogus message.
> 
> How might this work?
> 
> Assume remailers know the addresses of all (or most) of the other  
> remailers.  In other words, assume a given remailers knows if an inbound  
> message came from another remailer, or came from a non-remailer address.
> 
> All inbound messages to a remailer from a non-remailer address would be  
> considered a "use" of that remailer.  A remailer would maintain a list of  
> the addresses of "users" and would occasionally send bogus messages to a  
> randomly selected entry from its user list.  Inclusion into the list would  
> be automatic.  The list would be a large, but fixed sized FIFO, with old  
> entries dropping off the end automatically.
> 
> If the remailer system uses Digital Postage, then perhaps the bogus  
> message could be a token for a free Digital Stamp, good for one message.

However, there would be a record of addresses which anonymous mail had
been sent to- probably not a good idea.  Julf's anonymizer has such a
record, but I thought part of the idea of the cypherpunk remailers was to
eliminate these records.

I do find the digital postage discussion interesting... perhaps this would
be a way Julf could pay the bills on his system.  How exactly would this
work?  Would a "stamp" be a large random number?  Would a stamp be tagged
to prevent use by another user, or remain individually anonymous, but PK
encrypted to the purchaser?  Would full fledged Chaumian digital cash be
implemented?

Perhaps creating remailer stamps would be the best way to actually
implement a test bed for the Cypherpunk Credit union.  Start small with
remailer stamps, work the bugs out of the system, then slowly expand.

-john
jdblair@nextsrv.cas.muohio.edu