>In the Kademlia adaption for Bittorrent a peer's address (NodeID) is to be generated randomly, or more appropriate: arbitrarily. Because randomness isn't verifiable, an implementation can advertise itself with popular NodeIDs or even change them on a per-packet basis.
At the end of the slides they suggest sha1(ip+port) as a possible fix. This would increase the barrier-to-entry of a Sybil attack to the point where an attacker needs to be able to spoof IP addresses or connections. However, I believe that a sufficiently motivated and financially equipped attacker may already exist who would still be able to attack this scheme. Perhaps an alternative to sha1(ip+port) could be some form of cryptographic signature scheme, where the NodeID is a public key or hash of a public key, and a node is only considered "real" if it is at least able to sign responses with the private key that corresponds with the NodeID.
Maybe operators of nodes should be allowed to tweak some kind of setting that controls how paranoid the node should be of Sybil attacks.
Maybe it would be possible to include some kind of hashcash or Bitcoin scheme to make Sybil attacks more costly. There has to be some way of requiring an attacker to expend considerable computation power.
A little bit off topic, but I tried to get a developer API key for Bittorrent Sync, and never heard of them.
Same thing for Bittorrent Live.
Has anyone been successful in getting those ? Also, with the twitch flop (quality of the website, lags, 60 sec delay, PR problems) why don't we hear more about the Live service ?
BTSync is the obvious "Duh!" answer. Since its UDP traffic, controlled by DHT (so long as you disable their central tracker in your conf) and updates on the fly.
What I wind up doing (since I don't trust BTsync) is using inotify to watch the sync directory + mktorrent to create a new torrent on file change + pypush to push the new .torrent to various servers
Well in theory you can store data for anything in a DHT, not only an infohash. So you could have your program query the DHT for the key "MySoftware-Latest" and store under that key the infohash for the latest version.
I don't know how much flexibility there is in popular DHT implementations as to what you can store for a given key, and you will need a server of yours to continuously refresh the data and keep it alive in the DHT.
nly|12 years ago
Real-World Sybil Attacks in BitTorrent Mainline DHT: http://www.cs.helsinki.fi/u/lxwang/publications/security.pdf
Crawling BitTorrent DHTs for Fun and Profit: https://jhalderm.com/pub/papers/dht-woot10.pdf
Profiling a Million User DHT: http://www.michaelpiatek.com/papers/dht_imc_falkner.pdf
Lying To The Neighbours - Nasty effects with tracker-less BitTorrent: http://events.ccc.de/congress/2010/Fahrplan/events/4210.en.h...
oakwhiz|12 years ago
>In the Kademlia adaption for Bittorrent a peer's address (NodeID) is to be generated randomly, or more appropriate: arbitrarily. Because randomness isn't verifiable, an implementation can advertise itself with popular NodeIDs or even change them on a per-packet basis.
At the end of the slides they suggest sha1(ip+port) as a possible fix. This would increase the barrier-to-entry of a Sybil attack to the point where an attacker needs to be able to spoof IP addresses or connections. However, I believe that a sufficiently motivated and financially equipped attacker may already exist who would still be able to attack this scheme. Perhaps an alternative to sha1(ip+port) could be some form of cryptographic signature scheme, where the NodeID is a public key or hash of a public key, and a node is only considered "real" if it is at least able to sign responses with the private key that corresponds with the NodeID.
Maybe operators of nodes should be allowed to tweak some kind of setting that controls how paranoid the node should be of Sybil attacks.
Maybe it would be possible to include some kind of hashcash or Bitcoin scheme to make Sybil attacks more costly. There has to be some way of requiring an attacker to expend considerable computation power.
ritonlajoie|12 years ago
Same thing for Bittorrent Live.
Has anyone been successful in getting those ? Also, with the twitch flop (quality of the website, lags, 60 sec delay, PR problems) why don't we hear more about the Live service ?
unsignedint|12 years ago
unsignedint|12 years ago
steeve|12 years ago
Sort of like an ever continuing magnet link if you will?
aroch|12 years ago
What I wind up doing (since I don't trust BTsync) is using inotify to watch the sync directory + mktorrent to create a new torrent on file change + pypush to push the new .torrent to various servers
revelation|12 years ago
I don't know how much flexibility there is in popular DHT implementations as to what you can store for a given key, and you will need a server of yours to continuously refresh the data and keep it alive in the DHT.