blob: d6a6bcf2b08cf487e049487eef342a7725d03f17 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
|
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.
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.
...
=====
<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);
|
