[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: (dis)advantages of DC-Net vs remailers
> 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.
The bandwidth is the easy part. Building clients that do a DC protocol with
real-world reliability and resistance to denial of service is the hard part.
And doing all this in a package that would be easy to get people to use is
probably the hardest part.
The only way I know of to deal with denial of service is for everyone to
reveal their flips and kick the attackers out of the net. However, if
someone is legitimately transmitting that round they loose their
untraceability. So pretty much the only way to do it is ensure that only one
participant has permission to transmit and that the participant with
permission gets to decide if everyone shows their hands.
A way to do this would be to have a separate reservation phase of the
protocol. In the reservation phase all of the participants 'bid' on a token.
Whoever gets the token has permission to transmit during that round. If
collisions have been occurring, the participant holding the token can demand
that everyone reveal their flips. I think there is a paper describing a
protocol for this, but I don't have access to a library with crypto material.
The protocol for distributing the token would be somewhere between an
All-Or-Nothing-Disclosure-Of-Secrets and a poker card dealing protocol. Only
one person should be able to get the token and nobody should know who got it.
To make it more complicated, for people to be able to transmit in a timely
fashion, you should be able to specifically request the token when you want
it (so you would have a 1/n chance of getting it with n being the total
number of participants wanting to transmit that round), and not have any
chance of getting it when you don't want to transmit. In addition the
generation of the token(s) should be secure so that none of the participants
have to trust anyone that only one participant can get a valid transmit
I can think of a way to do this with a mental poker protocol. The only
problem is there is always a 1/n chance of getting the transmit token (where
n is the total number of participants), whether you want it or not. I
believe it also requires some trust in the 'dealer'... Anyway, the deck
would consist of 1 transmit token and n-1 blank tokens. Immediately after
the transmit phase the participant holding the token can optionally demand
that everyone reveal their flips. To do that the participant would reveal
their valid transmit token. At that point everyone else would reveal their
blank transmit tokens (to make sure there are no duplicates). If anyone
refuses to reveal their blank token, they are removed from the net. Once
it's been determined that there is only one valid transmit token, everyone
reveals their flips.
In theory all of this stuff would work, but implementing it is a different
story. For a DC net to be practical, it would have to run completely without
human intervention. Maybe a client could be placed in your .login or shell
rc file and would run in the background whenever you were logged in. It
could keep running after you logged out if you had a message in your queue to
be sent out. Clients must be smart enough to synchronize rounds and remove
participants who aren't responding fast within time-outs, etc...
automatically attempt to 'lay a trap' when collisions have been occurring,
figure out who is disrupting or not following protocol and remove them or
alternately have the client drop out of the DC-Net when protocol hasn't been
followed to satisfaction (duplicate tokens in one round, etc...), etc...
Quite a tall order, and for how much more untraceability than the current
remailer system? Even if it is implemented you still have to get people to
use it. The current remailer system can be used with no software
Still, it's an interesting prospect, as it offers real sender and receiver
untraceability within the group of participants. But is it worth it?
(apologies for the length...)