1994-07-28 - Latency vs. Reordering

Header Data

From: hughes@ah.com (Eric Hughes)
To: cypherpunks@toad.com
Message Hash: 79f80d14d1e90811fd339d5cf5fa1adf54a4b139e4e9e20e431ad671d3292205
Message ID: <9407281527.AA00454@ah.com>
Reply To: <940727141624e1Sjgostin@eternal.pha.pa.us>
UTC Datetime: 1994-07-28 15:59:48 UTC
Raw Date: Thu, 28 Jul 94 08:59:48 PDT

Raw message

From: hughes@ah.com (Eric Hughes)
Date: Thu, 28 Jul 94 08:59:48 PDT
To: cypherpunks@toad.com
Subject: Latency vs. Reordering
In-Reply-To: <940727141624e1Sjgostin@eternal.pha.pa.us>
Message-ID: <9407281527.AA00454@ah.com>
MIME-Version: 1.0
Content-Type: text/plain


	True. For small numbers of files re-ordering is important. On the
   large scale, latency serves both purposes. I tend to think of these things
   on the large scale, which is the reason I pointed things that way.

That's fine, but say reordering if you mean reordering, and not
something else that merely yields reordering.  Reordering is the
important concept.  Latency is a derivative concept.  Reordering is
more important than latency.

If you use the "collect-and-shuffle" method of reordering, you get
_guaranteed_ reordering.  If you use random delay, you get no
guarantees until you do the detailed mathematical analysis of just how
much reordering that gets you.  Merely _measuring_ the amount of
reordering in a continuous message stream is an interesting
definitional problem.  Calculating these measures will require some
fairly sophisticated probability theory, and NO ONE HAS DONE THAT YET.

Cryptography is about assurances as much as actual security.  Adding
latency now yields NO GUARANTEES about the amount of reordering,
because the work has not yet been done.  Adding latency gives only
warm fuzzy feelings, and no understanding.

The maxim applies here: "I you don't understand how it works, don't
trust it."

Eric






Thread