How are DHTs secure? What prevents someone from flooding them

>>60226859
>>Bob uploads 50000 files with hashes such as
>>b76a71c4...504c535c
>>b76a71c4...b3826ddd
>>b76a71c4...1108d467
Sorry, could you clarify how this has any negative affect whatsoever?

>>60226883
The nodes with IDs closest to the hash of the key are responsible for storing it, no? So if one floods the nearby nodes with garbage you could censor a specific file without having to attack the (as a whole) resilient network.

>>60226896
Could you explain how this changes anything?
Why would this "flood" the torrent out?
If you request by the hash, you get the fucking torrent.

The spaces that nodes are responsible for is only a finite set of keys, you can't "flood" it.

Now why don't you tell me how you are going to generate 50000 all with a similar hash.

>>60226954
Do you understand how DHT works? The node with the closest ID is responsible for file storage. So if you flood the node with garbage, chances are the node will store that instead of the file.
Brute force. You only need a partial collision, log(amount of nodes)/log(2) bits in common at the start should be enough. A common GPU can generate SHA256 or similar at 1gh/s. So for one million nodes you need a 20 bit collision, which you can generate 1000 times per second with ordinary graphics card.

>>60226999
>Do you understand how DHT works?
Do you?

>chances are the node will store that instead of the file.
And why would it do that?

>>60227024
Yes.

Because it has no way to differentiate between "legitimate" files and flooding as far as I can see.

>>60227032
And how will that drown out the legit torrent?

If I request b76a71c4...a03502ad, I will get Alices torrent. Why would it return any other torrent?

>>60227051
Because there's not enough space to store Alice's torrent and the garbage. The node with hash closest to b76a71c4...a03502ad doesn't have unlimited space, so it will either store the garbage or the torrent. If there's more garbage, the probability of that using all the storage goes up.

dht poisoning is the easiest way to stop bittorrent swarms from growing.
it's done all the time.
GNUnet's dht implementation is interesting because it does a random keyspace shuffle before the actual request is done which partially mitigates the effect of dht shitflooding.
t. researching gnunet for i2p

>>60227086
Yeah, maybe if we had 100mb hard drives.

>>60227086
>The node with hash closest to b76a71c4...a03502ad doesn't have unlimited space
it's just a pointer lad

>>60227111
the dht kbuckets used in most bittorrent clients are tiny af

>>60227104
So how is this mitigated in practice? Do you have any links?

>>60227145
it's not mitigated in bittorrent because you can't change mainline's protocol this far in the game.

>>60227086
There isn't a single node closest b76a71c4...a03502ad in practice, DHT is a distributed structure,torrent metadata will be stored in multiple nodeids that can be find with a best effort. To control a hashs space you don't flood hashes, you flood nodeids closer to b76a71c4...a03502ad and send fake info to requesters. There is a DHT security extention designed to prevent that
http://www.bittorrent.org/beps/bep_0042.html
It's implemented by libtorrent-rasterbar and not likely to be implemented by utorrent.
>>60227169

>>60227169
Okay. So how come it isn't a bigger problem then? Legal issues?
>>60227241
Thanks for the info. How were the mask bits chosen? (ip & 0x030f3fff)