[mnet-devel] Grid Of Trust -- pre-design

Some Guy amichrisde at yahoo.de
Tue Dec 9 11:39:15 GMT 2003


 --- Jim Dixon <jdd at dixons.org> wrote: 
> On Sun, 7 Dec 2003, [iso-8859-1] Some Guy wrote:
> > > > So what can an adversary do if he can run a bad guy in each cell?
> > > >
> > > > Premix routing will be safe even if the adversary did run a node in every cell.
> > >
> > > Proof?
> >
> > Premix will work as long as a certain fraction of the pickable
> > neighbors at each step are good.  If that fraction is f=16/17 that's
> > ok.  It can even survive f=10%.  It's just a question of how long you
> > have to make the chains before you think it's safe enough.
> 
> This is simply another assertion without any proof.  And how you could
> get f==16/17 with 16 members per cell is puzzling in the extreme.

Read the paper on Tarzan.  They use IP subnets as thier limited resource.  Read their proofs. 
This grid proposal is an improvement on thier design, because you don't have to have all N:N
connections to check identities.

> > > > The DHT would still function pretty well if you left the adversarial
> > > > nodes in there,
> > >
> > > Proof?
> >
> > I can demand a certificate on an insert prooving that all members of a
> > cell are hosting the data.
> 
> Who is the certificate from?  Why should they pay any attention to your
> request?  Why shouldn't they lie sometimes?  all of the time?

You know that on average a certain fraction of the identities in a cell will be ok.  Anyone can
know if an RSA key belongs to a cell.  Nobody but them can sign with those keys.  If you suspect 1
on average could be hostile, demand a recept from 2.  If a neighbor says there aren't 2 in that
cell, he's lieing; excomunicate him and try again.
 
> > I can demand a certificate on a request prooving that all members deny
> > having the data.
> 
> Who is the certificate from?

>From identities within the cell.
 
> > > >                but you could do better if neighbors would test each
> > > > other's behavior.
> > >
> > > Proof?
> 
> No proof, no suggestion as to how this is to be done.

Sure I'll write up a 20 page paper.  No wait actually I was expecting someone like Jim to be able
to explain how a "fragmented network" could easily identify its misbehavers and remove them.

> > No it's 16:1.  There were 16 normal guys there (on average).  Then
> > some jerk decide to put his node in there too.  To get it to 16:2 that
> > jerk would have to calculate twice the hash cash.
> 
> The network under discussion has grown.  Throughout the time of growth,
> the adversary has steadily added nodes, maintaining an average of one
> compromised node/cell.  The ratio is 15:1 because we have 16 nodes/cell.
> This has been the premise thoughout this discussion.  We have been
> discussing just how difficult this would be to do (answer: not very, for
> an adversary with large resources).

Well, I was suggesting looking at million node network.  The adversary doesn't have to use all of
his hundreds of thousands of IDs.  He just has to pick a few and run nodes there where he can do
damage.  Sure he's welcome to run mostly good nodes throughout the system and help out
performance. :-)  It's no big deal.  I assumed 1 million good nodes, plus an advesary.  You're
couting a million nodes with x% advesarial.  My point is just that the good nodes don't become
less, because the advesary is there.  I think it's silly that such a big deal of this is made.

__________________________________________________________________

Gesendet von Yahoo! Mail - http://mail.yahoo.de
Logos und Klingeltöne fürs Handy bei http://sms.yahoo.de


-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
mnet-devel mailing list
mnet-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mnet-devel




More information about the Mnet-devel mailing list