From: Hal <hfinney@shell.portal.com>
Date: Thu, 26 Jan 95 08:50:23 PST
To: cypherpunks@toad.com
Subject: Re:  Reordering, not Latency (Was: Re: Remailer)
Message-ID: <199501261649.IAA21706@jobe.shell.portal.com>
MIME-Version: 1.0
Content-Type: text/plain


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

From: Michael Handler <grendel@netaxs.com>
> On Wed, 25 Jan 1995 Louis Cypher wrote:
> 
> > 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. Otherwise you are still vulnerable to 
> traffic analysis (which is an art, not a science, remember).

I think there is a small terminology problem here.  In Eric's writings,
latency refers to delaying message remailing; reordering refers to
sending messages in a different order than they arrive.  I think it is
obvious that reordering is necessary in order to have any mixing; latency
may provide reordering, but it is not guaranteed to do so.  Latency
without reordering is not of much use.

More recently the discussion has been contrasting simple batch reordering
versus a form of reordering where some messages are "carried over" from
one batch to the next.  In the recent context this carry-over process is
being referred to as adding latency.  I think the recent comments about
the advantages of latency refer to the additional statistical confusion
which this carry-over process may add.

So these comments don't contradict Eric's earlier statements, but rather
the terminology has shifted slightly.  Reordering is still the primary
necessity; now it appears that reordering with some latency (carry-over)
is superior to simple batch-based reordering.

Hal

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

iQBVAwUBLyfSgBnMLJtOy9MBAQH2CwH/WbGPjJmI8yDmlfOblU+fbC9+tlqILluQ
UpAxSFUg00u2QpHdA2a52Yvzb7Oi+oe6WvwdZ7SBFfbLTksa8Q8FVg==
=hWiJ
-----END PGP SIGNATURE-----