2013-07-10 06:27:56 +08:00
|
|
|
List of possible attacks on the current DHT:
|
|
|
|
|
|
|
|
|
|
create thousands of fake nodes cloning one client_id and flood our DHT with
|
|
|
|
|
them.
|
|
|
|
|
|
|
|
|
|
create thousands of "real" nodes that do nothing but shit up our DHT with fake
|
|
|
|
|
crap.
|
|
|
|
|
|
|
|
|
|
...
|
|
|
|
|
|
|
|
|
|
Possible solutions:
|
|
|
|
|
|
|
|
|
|
Each client_id is the public key of the peer so it would be trivial to encrypt
|
|
|
|
|
the DHT requests with crypto_box(). This would completely defeat the first
|
|
|
|
|
attack.
|
|
|
|
|
|
2013-07-11 20:41:24 +08:00
|
|
|
Make each peer send the information of at least one of his online friends in
|
|
|
|
|
every send nodes response. (Might be bad as any node can now know who our
|
|
|
|
|
friends are)
|
|
|
|
|
|
|
|
|
|
Limit the maximum number of peers with identical ips that we keep connected to
|
|
|
|
|
in our DHT. (Not a real solution)
|
|
|
|
|
|
|
|
|
|
Require each node to solve some kind of captcha in order to connect to the
|
|
|
|
|
network. (Bad idea.)
|
|
|
|
|
|
|
|
|
|
Require nodes to crack hashes or solve other computationally intensive
|
|
|
|
|
problems in order to be accepted in the network. (Kind of like bitcoin)(This is
|
|
|
|
|
probably a bad idea as our application needs to work on phones which are low
|
|
|
|
|
power devices)
|
|
|
|
|
|
|
|
|
|
Make each node test other nodes to see if they respond correctly before sending
|
|
|
|
|
them as part of their send nodes response.
|
2013-07-10 06:27:56 +08:00
|
|
|
...
|
2013-07-13 22:01:19 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
=====
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<slvr> DHT_hardening.txt > create thousands of "real" nodes that do nothing but
|
|
|
|
|
shit up our DHT with fake crap.
|
|
|
|
|
<slvr> This can be trivially solved by only storing verifiable data in the DHT.
|
|
|
|
|
<slvr> there is one attack you have not considered, which is based on the Sybil
|
|
|
|
|
attack
|
|
|
|
|
<slvr> I am assuming the DHT does say... a hash of a key in order to determine
|
|
|
|
|
which node to store data in, similar to Kad?
|
|
|
|
|
<slvr> If there happens to be a malicious node at that DHT address, they might
|
|
|
|
|
actively deny storing that data.
|
|
|
|
|
<slvr> This can be reduced by storing data at multiple places in the DHT
|
|
|
|
|
(equidistant points in DHT address space)
|
|
|
|
|
<slvr> Since DHT addresses are public keys, it is computationally infeasible for
|
|
|
|
|
an attacker to actively deny all storage locations.
|
|
|
|
|
<slvr> Recommended reading: S/Kademlia: A Practicable Approach Towards Secure
|
|
|
|
|
Key-Based Routing -- http://doc.tm.uka.de/2007/SKademlia_2007.pdf
|
|
|
|
|
<biribiri> Type: application/pdf; Size: 202KiB; Updated: 2033d 19h 32m 5s ago
|
|
|
|
|
(Tue, 18 Dec 2007 13:28:18 GMT);
|
|
|
|
|
<slvr> Tempering Kademlia with a Robust Identity Based System --
|
|
|
|
|
http://www.di.unito.it/~ruffo/concorso/Papers/p2p08.pdf
|
|
|
|
|
<biribiri> Type: application/pdf; Size: 145KiB; Updated: 1291d 23h 30m 12s ago
|
|
|
|
|
(Tue, 29 Dec 2009 09:30:28 GMT);
|
|
|
|
|
<slvr> Also of interest: "An Analysis of BitTorrent's Two Kademlia-Based DHTs"
|
|
|
|
|
--
|
|
|
|
|
http://www.tribler.org/trac/raw-attachment/wiki/AutoUpgradeToLastestVersion/
|
|
|
|
|
Measurement_of_Bittorrent_DHT_performance_and_deployed_clients.pdf
|
|
|
|
|
<biribiri> Type: application/pdf; charset=iso-8859-15; Size: 1.271MiB; Updated:
|
|
|
|
|
1669d 20h 25m 15s ago (Tue, 16 Dec 2008 12:44:08 GMT);
|
|
|
|
|
|
