1992-11-17 - The Dining Cryptographers Protocol

Header Data

From: Eric Hughes <hughes@soda.berkeley.edu>
To: Marc.Ringuette@GS80.SP.CS.CMU.EDU
Message Hash: cd653925e149ace541e20bc094bd64ac040a26341af203dd2e5f306ef8d61e0f
Message ID: <9211171140.AA14731@soda.berkeley.edu>
Reply To: <9211161815.AA29148@toad.com>
UTC Datetime: 1992-11-17 11:40:49 UTC
Raw Date: Tue, 17 Nov 92 03:40:49 PST

Raw message

From: Eric Hughes <hughes@soda.berkeley.edu>
Date: Tue, 17 Nov 92 03:40:49 PST
To: Marc.Ringuette@GS80.SP.CS.CMU.EDU
Subject: The Dining Cryptographers Protocol
In-Reply-To: <9211161815.AA29148@toad.com>
Message-ID: <9211171140.AA14731@soda.berkeley.edu>
MIME-Version: 1.0
Content-Type: text/plain


Marc.Ringuette writes:

>My spin on the Dining Cryptographers Protocol is, it's nifty and
>theoretically strong, but in practice mixes are better for almost all
>uses.  [...]  N is typically 100-10000, and M is typically 2-10.
>Mixes are more efficient.

Let me continue to be a broken record.  Cryptography is all economics.

You want unconditional security, you pay.  Period.  Sometimes it's
worth it, sometimes it's not.  It is not up to the cryptographer to
make the economic judgement, it is up to the user.

>One advantage of DC-nets is that they're instant; with mixes there must be
>some delays in order to accumulate enough cover messages to defeat traffic
>analysis.

This idea of "delays" providing security for a mix is a common, but
incorrect, notion.  I don't think Marc is incorrect about this here,
merely unclear.  In a well used mix system, the latency time to
accumulate ten messages would be only a few minutes.

It is the reordering of the output messages with respect to the input
that provides mix security.  Any delay in merely a consequence of the
time to collect.

Eric





Thread