True, but: * Even if what you said was true, the data would only be multiplied by 4 times, not five, since it is 5 networks each with 4 nodes * This is only a disincentive to flooding, it should only have to be used in an emergency * The papers discuss ways that the data throughput can be slowed down when data is not being sent (so there is only a slow flow of data until a transmission request when the data speeds up to carry the transmission), this dramatically reduces the problem, in fact, if the "quiet" data rates are sufficiently low, then they are insignificant and you only get a 200% increase in data-flow during "busy" periods * If people were really concerned about efficiency then they would just use IRC * If you think this is inefficient you should see some of Chaum's proposed solutions!
Ian. On Mon, May 14, 2001 at 02:56:25PM -0500, Scott Gregory Miller wrote: > Problem there is that each time you duplicate these rings, you start > having to send more and more traffic. The rings have to constantly be > sending data, so if you have 5 of them, then you've multiplied the amount > of traffic (even when no data is being sent) by 5. > > > On Mon, 14 May 2001, Ian Clarke wrote: > > > A DC or Dining Cryptographers ring is a way that a number of nodes on > > a network can form a ring that works like ethernet, where anyone on the > > ring can broadcast information to the others but without betraying their > > identity. This can work over TCP/IP or any other communication > > protocol. Scott wants to use it for anonymous invite-only IRC but there > > is a problem, someone could flood the ring making it useless, and you > > can't know who it is. See: > > > > http://www.nyx.net/~awestrop/crypt/diningcr.htm > > > > ...for more info. > > > > Ok, so I have been thinking about a way to protect a DC communication > > ring* from an abusive participant. > > > > Basically, let's say that people A, B, C, D, and E are happily talking > > to each other anonymously using a DC ring, when someone starts to flood > > it, preventing communication. As soon as this occurs, the system goes > > into "Mc Carthy mode". 5 new rings are formed, the first with people B, > > C, D, and E, the second with A, C, D, and E, the third with A, B, D, and > > E, the fourth with A, B, C, and E, and the fifth with A, B, C, and D ie. > > there are five different rings each leaving out one participant. Each > > participant randomly selects two of the rings they are on to broadcast > > their messages, and continue as normal, treating the 4 rings they are > > attached to as a single message source, but broadcasting on only 2 of > > those rings. If someone starts to abuse one or more of the rings then > > that ring is dropped. If they continue to be a pain in the ass then > > eventually then all rings that they are attached to will be dropped > > and everyone will know who they are. So basically, the rules are, play > > nice or we will figure out who you are. > > > > Now, of course, this has some negative implications for anonymity, in > > that when the network is in "Mc Carthy" mode, people lose some of their > > anonymity since, lets say that a message is broadcast on rings ABCE and > > ABCD, then they will know that the message must have been broadcast by > > node A, B, or C. Of course, the bigger the ring, the less acute this > > problem is. > > > > It may be possible to reduce this problem, where nodes only broadcast on > > one ring, and other nodes on that ring then randomly self-select (ie. > > they wait for a random amount of time, and if nobody else has done it, > > rebroadcast the message on a different ring than the one it came in on). > > > > So this approach works fine where there is only one malicious > > participant, however if they are two then between them, they will be > > able to flood all rings, and this approach won't work. The solution > > here would be to create subrings for all permutations where two nodes > > are left out, and repeat the process. Of course, this would increase > > the loss of anonymity described above, but again, the larger the > > network, the less of a problem this is. > > > > Thoughts? > > > > Ian. > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20010514/615c2e80/attachment.pgp>
