1994-08-07 - Latency vs. Reordering

Header Data

From: hughes@ah.com (Eric Hughes)
To: cypherpunks@toad.com
Message Hash: d3ad9e33c55a76a7e844d871fe051b2ddac0a122b49c9b1000c71407970dadf2
Message ID: <9408071655.AA18215@ah.com>
Reply To: <199408070216.TAA09025@jobe.shell.portal.com>
UTC Datetime: 1994-08-07 17:23:58 UTC
Raw Date: Sun, 7 Aug 94 10:23:58 PDT

Raw message

From: hughes@ah.com (Eric Hughes)
Date: Sun, 7 Aug 94 10:23:58 PDT
To: cypherpunks@toad.com
Subject: Latency vs. Reordering
In-Reply-To: <199408070216.TAA09025@jobe.shell.portal.com>
Message-ID: <9408071655.AA18215@ah.com>
MIME-Version: 1.0
Content-Type: text/plain


   This suggests, that IF YOU COULD TRUST IT, a single remailer would be just
   as good as a whole net.  

If you could trust it and if it were large enough.  There's scaling
reasons to use multiple remailers as well.

Consider a network of mailers running on a private network with link
encryptors.  Whenever you join two nodes with a full-time link
encryptor you remove the information about message arrival and
departure, which is to say that you remove all the remaining
information not already removed by encryption and reordering.

In other words, two remailers (physical) hooked up with link
encryptors are almost the _same_ remailer for purposes of traffic
analysis, and almost only because of the link latency and relative
bandwidth.  Likewise, multiple remailers hooked up with link
encryptors all collapse to the same node for traffic analysis.  Open
links between two remailers which are connected otherwise by a path of
encrypted links turn into an edge from the collapsed remailer set back
onto itself.

Simulating any of the salient features of a link encryptor over the
Internet is an interesting exercise, particularly in regard to price
negotiation with your service provider.

Eric






Thread