Quoting Michael Rogers <[email protected]> from ml.p2p.hackers: :It doesn't seem like that would be very difficult. If there's some :proof-of-work step that makes it hard to generate an ID, that step has :to be easy enough for an ordinary user's device to perform when the :user first install the app. Let's say the proof-of-work takes a minute :of CPU time - then an attacker with the same hardware as an ordinary :user can generate 1440 IDs per day, displacing 1440 peers from the :buckets for some random DHT keys. If the attacker's only interested in :one key, 1440 random IDs might not be very useful, but if the DHT is :full of content the attacker's interested in, all those node IDs can :be kept around until they come in useful.
Any scheme that messes up with DHT node IDs is bound to leave a statistical trace tha can be detected and circumvented, making the cost of performing a Sybil attack orders of magnitude more costly. Here is the link to the paper I was mentionning the other day: http://hal.inria.fr/docs/00/49/05/09/PDF/HotP2P10-KAD_DHT_attack_mitigation-cholez.pdf Moreover, all DHT keys should be totally random and freely computed. Any computation scheme of the DHT key through a mechanism that ties it to the user somehow for purpose of external "verification" is dangerous because it leaves users picking an ID that generates lots of traffic unable to do anything about it. Raphael _______________________________________________ p2p-hackers mailing list [email protected] http://lists.zooko.com/mailman/listinfo/p2p-hackers
