Also do a google on +p2p +byzantine (there's been lots of work on the "Byzantine Generals Problem" - i.e., 'nobody trusts each other')
Miles Fidelman Michael Rogers wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > I'm not sure whether your message just came through to the list or > whether I just noticed it. Either way, I hope it's not too late to reply. > > The following papers describe attacks that can be carried out by > malicious nodes in structured P2P networks: > > E. Sit and R. Morris. Security considerations for peer-to-peer > distributed hash tables. 1st International Workshop on Peer-to-Peer > Systems (IPTPS ?02), Cambridge, MA, USA, March 2002. > > http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.11.7175 > > M. Castro, P. Druschel, A. Ganesh, A. Rowstron, and D.S. Wallach. > Secure routing for structured peer-to-peer overlay networks. 5th > Symposium on Operating Systems Design and Implementation, Boston, MA, > USA, December 2002. > > http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.118.1870 > > I'd recommend checking out the papers that cite those papers, some of > which propose solutions to some of the attacks. > > Cheers, > Michael > > On 13/03/13 05:44, offbynull wrote: >> Hi, >> >> Does anyone know of any strategies to prevent, identify, or >> work-around malicious nodes in a structured overlay? I'm >> specifically interested in Chord's ring overlay. It seems like >> there are a lot of things a malicious node could to to interfere >> with normal operations (e.g. routing / lookup / etc..), or to >> bypass certain regions of the ring. >> >> Examples of things that a malicious node could do ... >> >> 1. Imagine someone wanted to prevent others from accessing a >> key-value pair. That person would create a malicious node with an >> id of hash(key), ensuring that queries for that key would end up at >> the malicious node. When the malicious node receives queries for >> that key, it simply ignores them or responds that the key was never >> set. >> >> 2. This is similar to the one above. Imagine someone wanted to >> prevent others from accessing a key-value pair, but a legitimate >> node already existed with an id of hash(key). That person would >> create a malicious node with an id of hash(key) - 1. When other >> nodes ask the malicious node to be routed to that key, the >> malicious node would respond with a node other than it's successor, >> ensuring that the request never gets routed to its true >> destination. >> >> 3. Imagine someone wanted to cut out a portion of the nodes in the >> overlay. That person would create a malicious node that has its >> finger table set to skip over a bunch of existing nodes in front of >> it. >> >> >> Are there strategies to deal with this, or is this just something >> that's expected with Chord's design (as in peers can't be untrusted >> nodes)? >> >> _______________________________________________ p2p-hackers mailing >> list [email protected] >> http://lists.zooko.com/mailman/listinfo/p2p-hackers >> > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > > iQEcBAEBAgAGBQJR9o5bAAoJEBEET9GfxSfMj0AIALZ+lSnA7GDh+Y3iifdVotwK > YXdjGjv+qJcvOIO/rHtTEyPMzp7yqz0X0VxeiC8XIjXP6rwvFGOXuClqd0NAjFW9 > lHYtO9tHBkCV/LOU5hHrD3510Ry6gYkuDnyDeWBlwQ2i/zUU160PqGr+Esd1IpNP > zu5JKSHHq61wr5GisXOB+pWOxrKEEKtQAtv3ibFNBDXhGyJwg+U/LCe9Q14V9Q4t > BiOKgce8xHhbytY8B/5t3HW6cCavQAq/TR0CfjpWRtz823hs0lTdepJJXPnKVYIo > HD0u+cwnCGr7LNF5szMvkvdEkyXsbXGLYX+2cK7aHBPO4kGoXw5DrNAhS2Gkh+g= > =xMmD > -----END PGP SIGNATURE----- > _______________________________________________ > p2p-hackers mailing list > [email protected] > http://lists.zooko.com/mailman/listinfo/p2p-hackers -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra _______________________________________________ p2p-hackers mailing list [email protected] http://lists.zooko.com/mailman/listinfo/p2p-hackers
