REMAIL: Cover traffic

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.

For cover traffic to be useful, it would have to be indistinguishable
from real traffic as it enters and leaves the network.  So messages
aimed at known "bit bucket" addresses, or at a few cooperating
individuals who accept and discard incoming addresses (the same thing,
really) will not help.

Hal

Hal Finney on sending noise messages:
> 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. 

This is still a big win, since it expands the traffic analyst's task from
determining what goes in and out of a single remailer to what goes in
and out of the entire network.  The per-remailer traffic, for now
and in the forseeable future, is too small to effectively mix traffic
at that level; but traffic across the entire network may soon be
sufficient for that.  We get a reasonable digital mix with over
an order of magnitude less real traffic by using noise messages.

My biggest current concern as an individual, or potential 
business remailer user, is not some super-duper
netwide traffic analysis by giga-bureaucracies that
have much bigger fish to worry about than myself; it is rather
is the _manual_ tracking of message via hacking of remailer 
sites or collusion by remailers, who seem to all
log their messages.  If I was to send out a message I really wanted 
hidden right now, I would generate quite a bit of noise to go along
with it, so that the easy _manual_ tracking of messages that can
practically occur now would be foiled.

> Message
> aimed at known "bit bucket" addresses, or at a few cooperating
> individuals who accept and discard incoming addresses (the same thing,
> really) will not help.

Sure they will.  Every bit bucket address adds another node that
the opponent must monitor; most opponents will quickly be overwhelmed
by the task of sniffing out just a few bit-bucket PCs on private "Little 
Garden" style networks.  Most folks who make serious use of remailers (with
nested-encryption scripts, etc.) can also easily set themselves up
as bit-bucket addresses.  Realistic-looking accounts can be set up
at many sites and used as nothing but bit buckets.   (Remailer users
can of course use real addresses at bit buckets right now, but this
is rather rude!)

Noise messages and bit-bucket addresses may not be theoretically
interesting, but the provide major practical improvements.
I challenge cypherpunks to come up with designs for actual software
to distinguish quantized noise messages from real messages that 
can realistically be implemented on the Internet, not just scenarios 
that an extremely strong organization could theoretically implement,
by expending vastly much more effort than remailer users and operators.

Nick Szabo				szabo@netcom.com