Bittorrent spec says node ids taken at random from large numeric space. What prevents bittorrent clients from intentionally using the same node id as someone they want to attack?

Oh I see.. is it a hash of the participant's network address?

Is it doing chord routing? Because chord routing pushes requests for chunks to addresses whose hashes are lexicographically adjacent to the hashes of the chunks themselves.

@cwebber When I was implementing a toy bit of the DHT spec the only requirement was that it was cryptographically random IIRC.
@anarchosaurus @cwebber bittorrent dht attacks in the wild are often keyspace eclipse attacks.
@jeff @cwebber Thanks! I wanna read about these later - controlling a ton of nodes was the main thing I was thinking of too.

I guess if you could fake the .torrent dict and controlled enough nodes you could make a peer dl something nasty
@anarchosaurus @cwebber that requires a sha1 collision

doing dht node exhaustion for a certain infohash is possible but it's too expensive to deploy for everything "bad"
@jeff @cwebber Oh yeah, you're right. The infohash wouldn't match the fetched dict
@cwebber You're talking about the DHT, right? I think there might be a case made for it not really being a problem. An impersonating node could pass back fake data, but that'll ultimately be verifiable by the peer hashing the received data, right?

I'm interested in knowing what scenarios you're talking about though, it's an interesting problem :)
@cwebber nothing, but it doesn't really matter, the client will just keep refetching chunks until it gets them all.

@cwebber i think they just don't? to mitigate that i don't think it would be exploitable in any meaningful way except a potential dos

Sign in to participate in the conversation

Octodon is a nice general purpose instance. more