From: szabo@netcom.com (Nick Szabo)
Date: Wed, 17 Nov 93 23:51:21 PST
To: cypherpunks@toad.com
Subject: /dev/null for e-mail; remailer diffusion structures
Message-ID: <199311180751.XAA20320@mail.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain



Like zero in arithmetic, the "device" /dev/null serves a useful purpose 
as a kind of "syntatic glue" for Unix shell programs.  I wonder if
such a "bit bucket" for mail might also be useful for anonymous remailers.
A couple examples:

* To provide multiple endpoints for a mail message, so that
the remailer list becomes a tree (or at least one branch
with a bunch of leaves).  This might be done with syntax
like

Request-Remailing-To: remail@tamsun.tamu.edu
<remail@tamsun decrypts to reveal>
Request-Remailing-To: next@destination.com
Cc-Bit-Bucket: hfinney@shell.portal.com
Cc-Bit-Bucket: remailer@utter.dis.org

where "Cc-Bit-Bucket" causes the tamsun remailer to randomly
generate a message of identical size, paste a "Bit-Bucket:"
header, encrypt it with the hfinney remailer's public key,
and send it to hfinney.  When the hfinney remailer decrypts the
message and sees the "Bit-Bucket:" header it deletes the
message.  remail@tamsun repeats this process with 
remailer@utter.dis.org, and sends the real mail message
on to next@destination.com.   To the traffic
analyzer, bit bucket messages are indistinguishable from
real ones (as long as the sender properly encrypted
the next message layer with next@destination.com's public
key).

Remailer bit bucket branching might be useful for adding confusion
when it's impractical to delay the mail to mix it with other
traffic (either because it's time sensitive or due to
lack of other traffic).

Bit bucket accounts could be useful if the destination receives a 
regular, identifying pattern of traffic (eg a unique number or size of 
encrypted messages).  To foil traffic analysis, set up a bunch of
pseudonymous accounts at various sites that serve no other purpose 
than sending and receving bit bucket messages.  It then looks like 
many sites are receiving that pattern of traffic.

* To provide endpoints for confusion & diffusion loops.
For example:

Request-Remailing-To: remail@tamsun.tamu.edu
<remail@tamsun.tamu.edu decrypts to reveal>
Cc-Loop: 7 iterations: hfinney@shell.portal.com, remail@tamaix.tamu.edu
Request-Remailing-To: next@destination.com

Does the same as above, except the randomized carbon copy is
put in a loop between remail and hfinney (in real life we'll want 
more than two remailers in the loop).  After 7 iterations
remail dumps the message, terminating the loop.  Instead of
"Bit Bucket:" the remailers might paste a loop counter, where
0 causes the message to be terminated.

Remailers might set limits on the number of
loops and destination sites, charge postage, or both,
to make sure these techniques don't soak up the available
bandwidth.  With sufficient bandwidth and software tools
we might get fancy and be able to choose routing
patterns from trees, acyclic and cyclic graphs, 
randomized branching, fractal branching, etc.  
if we find any such patterns better at thwarting traffic 
analysis.

Nick Szabo				szabo@netcom.com