1994-08-06 - Re: Latency vs. Reordering (Was: Remailer ideas (Was: Re: Latency vs. Reordering))

Header Data

From: jdd@aiki.demon.co.uk (Jim Dixon)
To: cypherpunks@toad.com
Message Hash: 556c9d09110b9ac120588b79cf806fd89d41ec207731f0b2fd65571f97087097
Message ID: <4087@aiki.demon.co.uk>
Reply To: N/A
UTC Datetime: 1994-08-06 17:30:57 UTC
Raw Date: Sat, 6 Aug 94 10:30:57 PDT

Raw message

From: jdd@aiki.demon.co.uk (Jim Dixon)
Date: Sat, 6 Aug 94 10:30:57 PDT
To: cypherpunks@toad.com
Subject: Re: Latency vs. Reordering (Was: Remailer ideas (Was: Re: Latency vs. Reordering))
Message-ID: <4087@aiki.demon.co.uk>
MIME-Version: 1.0
Content-Type: text/plain


In message <9408051716.AA14773@ah.com> Eric Hughes writes:

> Back to the start, I guess.
> 
> >   Specifically cryptographic elements are easily added to the system
> >       *	packets can be delayed for random intervals
> 
> Let me repeat:
> 
> REORDERING IS OF PRIMARY IMPORTANCE FOR REMAILER SECURITY.
> 
> ADDING LATENCY IS NOT.

No need to shout, we heard you the first time.	;-)

In a system that is carrying continuous traffic, random packet delay
is functionally identical to packet reordering.

If messages are fragmented, random delays on sending packets out is
functionally identical to reordering.

More importantly, RemailerNet as described defeats traffic analysis by
more significant techniques than reordering.  Reordering is a weak
technique.  The introduction of noise, 'MIRV'ing of messages,
fragmentation of messages, random choice of packet routes, and
encyphering of all traffic are stronger techniques.

--
Jim Dixon

-- 
+-----------------------------------+--------------------------------------+
|  Jim Dixon<jdd@aiki.demon.co.uk>  |	    Compuserve: 100114,1027	   |
|AIKI Parallel Systems Ltd + parallel processing hardware & software design|
|	     voice +44 272 291 316  | fax +44 272 272 015		   |
+-----------------------------------+--------------------------------------+





Thread