diff options
Diffstat (limited to 'docs/DHT_hardening.txt')
| -rw-r--r-- | docs/DHT_hardening.txt | 70 |
1 files changed, 0 insertions, 70 deletions
diff --git a/docs/DHT_hardening.txt b/docs/DHT_hardening.txt deleted file mode 100644 index d6a6bcf2..00000000 --- a/docs/DHT_hardening.txt +++ /dev/null | |||
| @@ -1,70 +0,0 @@ | |||
| 1 | List of possible attacks on the current DHT: | ||
| 2 | |||
| 3 | create thousands of fake nodes cloning one client_id and flood our DHT with | ||
| 4 | them. | ||
| 5 | |||
| 6 | create thousands of "real" nodes that do nothing but shit up our DHT with fake | ||
| 7 | crap. | ||
| 8 | |||
| 9 | ... | ||
| 10 | |||
| 11 | Possible solutions: | ||
| 12 | |||
| 13 | Each client_id is the public key of the peer so it would be trivial to encrypt | ||
| 14 | the DHT requests with crypto_box(). This would completely defeat the first | ||
| 15 | attack. | ||
| 16 | |||
| 17 | Make each peer send the information of at least one of his online friends in | ||
| 18 | every send nodes response. (Might be bad as any node can now know who our | ||
| 19 | friends are) | ||
| 20 | |||
| 21 | Limit the maximum number of peers with identical ips that we keep connected to | ||
| 22 | in our DHT. (Not a real solution) | ||
| 23 | |||
| 24 | Require each node to solve some kind of captcha in order to connect to the | ||
| 25 | network. (Bad idea.) | ||
| 26 | |||
| 27 | Require nodes to crack hashes or solve other computationally intensive | ||
| 28 | problems in order to be accepted in the network. (Kind of like bitcoin)(This is | ||
| 29 | probably a bad idea as our application needs to work on phones which are low | ||
| 30 | power devices) | ||
| 31 | |||
| 32 | Make each node test other nodes to see if they respond correctly before sending | ||
| 33 | them as part of their send nodes response. | ||
| 34 | ... | ||
| 35 | |||
| 36 | |||
| 37 | |||
| 38 | ===== | ||
| 39 | |||
| 40 | |||
| 41 | |||
| 42 | |||
| 43 | <slvr> DHT_hardening.txt > create thousands of "real" nodes that do nothing but | ||
| 44 | shit up our DHT with fake crap. | ||
| 45 | <slvr> This can be trivially solved by only storing verifiable data in the DHT. | ||
| 46 | <slvr> there is one attack you have not considered, which is based on the Sybil | ||
| 47 | attack | ||
| 48 | <slvr> I am assuming the DHT does say... a hash of a key in order to determine | ||
| 49 | which node to store data in, similar to Kad? | ||
| 50 | <slvr> If there happens to be a malicious node at that DHT address, they might | ||
| 51 | actively deny storing that data. | ||
| 52 | <slvr> This can be reduced by storing data at multiple places in the DHT | ||
| 53 | (equidistant points in DHT address space) | ||
| 54 | <slvr> Since DHT addresses are public keys, it is computationally infeasible for | ||
| 55 | an attacker to actively deny all storage locations. | ||
| 56 | <slvr> Recommended reading: S/Kademlia: A Practicable Approach Towards Secure | ||
| 57 | Key-Based Routing -- http://doc.tm.uka.de/2007/SKademlia_2007.pdf | ||
| 58 | <biribiri> Type: application/pdf; Size: 202KiB; Updated: 2033d 19h 32m 5s ago | ||
| 59 | (Tue, 18 Dec 2007 13:28:18 GMT); | ||
| 60 | <slvr> Tempering Kademlia with a Robust Identity Based System -- | ||
| 61 | http://www.di.unito.it/~ruffo/concorso/Papers/p2p08.pdf | ||
| 62 | <biribiri> Type: application/pdf; Size: 145KiB; Updated: 1291d 23h 30m 12s ago | ||
| 63 | (Tue, 29 Dec 2009 09:30:28 GMT); | ||
| 64 | <slvr> Also of interest: "An Analysis of BitTorrent's Two Kademlia-Based DHTs" | ||
| 65 | -- | ||
| 66 | http://www.tribler.org/trac/raw-attachment/wiki/AutoUpgradeToLastestVersion/ | ||
| 67 | Measurement_of_Bittorrent_DHT_performance_and_deployed_clients.pdf | ||
| 68 | <biribiri> Type: application/pdf; charset=iso-8859-15; Size: 1.271MiB; Updated: | ||
| 69 | 1669d 20h 25m 15s ago (Tue, 16 Dec 2008 12:44:08 GMT); | ||
| 70 | |||