NODE 82e62a29(dis)advantages of DC-Net vs remailers
"Wei Dai" <weidai@eskimo.com>Mon, 6 Feb 95 19:28:34 PST
-----BEGIN PGP SIGNED MESSAGE-----
tcmay@netcom.com wrote:
> Chaumian digital mixes--what you Americans call "remailers"--mainly
> solves the sender anonymity problem. Message pools, or broadcast to a
> group or site that includes the receiver, mainly deals with receiver
> anonymity. The combination of the two deals with both.
>
> Both are solved elegantly with the Dining Cryptographer's Protocol,
> about which much is written on this list every few months. Messages
> are "sent" in an Ouija-board fashion and received by the person who
> can successfully decrypt a public message sent over the system.
I tend to favor remailers + broadcasting + anonymous-return-addresss
over the DC-Net protocol. Let me list some of their relative
advantages and disadvantages. Please add to these if you can think
of more...
Advantages of DC-Net over remailers
- more flexible trust relationships - you can add your buddies to
the set of people who have to be compromised to trace you
- lower latency - don't have to wait for remailers to collect enough
mail for batches
- untracibility need not depend on assumptions about the enemy's
computational power
Disadvantages of DC-Net
- complexity - explaining the core concepts of a remailer takes only
a couple of lines, as opposed to a couple of screens for a DC-Net
Implementation of a DC-Net seems to be an order of magnitude
harder as well.
- more vulnerable to denial of service attacks
- MUCH higher bandwidth costs
I think over the long run the last factor will be most important. In
a DC-Net, for each bit one participant wants to send to another, EVERY
OTHER participant must broadcast a bit to ALL participants. I can
imagine a remailer-net with one million users, but I don't see any
possibility that a DC-Net can be scaled to that size.
Wei Dai
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBLzboXjl0sXKgdnV5AQEqqAP+JU2sgiESnFZm+CCgNNboXnL3uKg0GP4Z
y6NV+U56yGvPKzsi9suUiOpbuzwsYVaMnWIuqRCOaxic75SFsDi0NvjE1K4JgyXz
aoyVs1i+xlFKnfmZr1+7EAheUq7wlfSWdp0cnAhbNWSrC3cSuDiNGYciJQLW8GGv
3YUvmW+Xoj0=
=Aa+t
-----END PGP SIGNATURE-----
E-mail: Wei Dai <weidai@eskimo.com> URL: "http://www.eskimo.com/~weidai"
=================== Exponential Increase of Complexity ===================
--> singularity --> atoms --> macromolecules --> biological evolution
--> central nervous systems --> symbolic communication --> homo sapiens
--> digital computers --> internetworking --> close-coupled automation
--> broadband brain-to-net connections --> artificial intelligence
--> distributed consciousness --> group minds --> ? ? ?
NODE d785015bRe: (dis)advantages of DC-Net vs remailers
"James A. Donald" <jamesd@netcom.com>Mon, 6 Feb 95 20:46:27 PST
On Mon, 6 Feb 1995, Wei Dai wrote:
> I think over the long run the last factor will be most important. In
> a DC-Net, for each bit one participant wants to send to another, EVERY
> OTHER participant must broadcast a bit to ALL participants. I can
> imagine a remailer-net with one million users, but I don't see any
> possibility that a DC-Net can be scaled to that size.
Not so -- you merely have to broadcast to enough people.
But then the topology, and hence the complexity, gets worse.
This however merely reduces the bandwidth waste from n^2 to n*lg(n)
A further wrinkle -- forming DC nets of DC nets, can reduce the
bandwidth waste to lg(n)^2, which should scale adequately to cover
the cosmos, but then the complexity gets really scary.
And when you try to figure how to deal with denial of service
attacks in a big DC net that tries to use bandwidth with
tolerable efficiency -- I don't know if anyone has figured out
what would be involved -- I certainly have not.
---------------------------------------------------------------------
|
We have the right to defend ourselves | http://www.catalog.com/jamesd/
and our property, because of the kind |
of animals that we are. True law | James A. Donald
derives from this right, not from the |
arbitrary power of the omnipotent state. | jamesd@netcom.com