Re: Reordering, not Latency (Was: Re: Remailer)

[wcs@anchor.ho.att.com]

> > In recent discussions, the consensus 
> > was that message reordering was superior to (and the actual intent of) 
> > latency.  Reordering is not sufficient, a form of latency is required 
> > to make it effective.
> 	I have literally hundreds of messages archived from the CP list of
> several months back where Eric Hughes repeatedly states that reordering,
> not latency, is the key. Reordering of a sufficient magnitude will
> introduce latency inherently. 

Effective reordering is the key - as Louis Cypher's article showed,
there are forms of reordering which are NOT effective, though the requirement
for latency is really a consequence rather than a direct requirement.
There are six+ classes of packets that can go through a remailer:
1) Real packets from outside to be remailed to outside.
2) Hostile packets from traffic analysts* outside to outside.
3) Real packets from outside to users on the remailer itself.
4) Real packets from the remailer itself to outside.
5) Cover traffic packets from the remailer to outside.
6) Cover packets from outside friendly remailers.

Ingoring categories 3-6 for the moment, the problem with reordering
is that the remailer needs to reorder n _real_ packets to get a certain
level of security, but can't really tell real packets from hostile ones.
If the algorithm is simply to reorder and retransmit batches of n packets,
either en masse or in a stream basis as Louis suggests, 
the analysts can surround each real packet with n hostile packets
from known destinations to known destinations and therefore be able
to pick out the one real packet on the outbound.
The effect of latency L is to provide a reasonable probability that
n real packets will have arrived during time L, so the addition
of hostile packets does not prevent the mixing between the n real packets.

Outbound cover traffic is helpful, but unless it targets the same
destinations as the real traffic with some probability,
it may not be sufficient to prevent long-term pattern analysis
(and cover traffic is mainly useful when sent to other remailers
and their co-conspirators; cover traffic sent to a newsgroup
or innocent member of the public is generally recognizable as such...)
Inbound cover traffic is great, of course - I'm not sure if it
totally substitutes for real traffic?  Its best use is in systems
where real traffic users chain between remailers which also carry
cover traffic between them, but there's still some information that
can potentially be gleaned about a small** remailer-cloud viewed as a whole
by analysts forcing lots of traffic through the cloud, unless the
remailers implement adequate reordering models.

[* I was going to refer to traffic analysts by the usual term Bad Guys,
but someday one of us good guys may want to break into a net
run by Bad Guys, so I decided to stay neutral here :-)]

[** The current 15-20 remailers are still a relatively small cloud.]

		Bill