Le 15.05.2012 17:10, Raphael Manfredi a écrit :
Quoting Michael Rogers<mich...@briarproject.org> 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
p2p-hackers@lists.zooko.com
http://lists.zooko.com/mailman/listinfo/p2p-hackers
Hi all,
I would also add that changing the way the ID of peers are generated
once the DHT is already deployed can only be done in the very long run
because it breaks the compatibility between peers choosing their ID in
the old-untrustworthy way and the new ones. Dropping the support of
peers choosing the old ID generation is only possible when most of them
have already migrated to the new solution. That is one of the main
reason why I prefer to enforce the random ID generation in order to
mitigate sybil attacks rather than changing the way ID are computed.
By the way, an extended version of this paper cited by Raphael is also
available here:
http://www.springerlink.com/openurl.asp?genre=article&id=doi:10.1007/s12083-012-0137-7
<http://www.springer.com/alert/urltracking.do?id=Lc52ad2Ma0c369Sb02d6b3>
In particular, it includes in addition some monitoring results of the
KAD DHT highlighting many sybil attacks and some optimizations of the
protection from the feedback provided by Raphael when he implemented it
in gtk-gnutella. Many thanks to him!
I will make the extended article freely available for non-academic
people as soon as possible.
Best regards,
Thibault.<http://www.springer.com/alert/urltracking.do?id=Lc52ad2Ma0c369Sb02d6b3>
_______________________________________________
p2p-hackers mailing list
p2p-hackers@lists.zooko.com
http://lists.zooko.com/mailman/listinfo/p2p-hackers
