BitTorrent secures and open-sources DHT bootstrap server(engineering.bittorrent.com)
engineering.bittorrent.com
BitTorrent secures and open-sources DHT bootstrap server
http://engineering.bittorrent.com/2013/12/19/dht-bootstrap-update/
4 comments
Re: the last link
>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.
>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.
Hi, that last link was my talk from 3 years ago. Last year at 29C3 a couple of friends proposed doing this kind of security with elliptic curve cryptography. See the lightning talks recordings. Their code is here: https://github.com/rtreffer/dht
The Youtube link has disappeared, unfortunately, unless there's a better link than this one: https://events.ccc.de/congress/2012/wiki/Lightning_Talks
I'll be at 30 ;)
> 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
What stops me from creating 10 million keypairs and spamming them in to the DHT?
What stops me from creating 10 million keypairs and spamming them in to the DHT?
That's a great question, and since there's a well-described public specification for such a scheme[0], I'd encourage you to look for similar attack vectors.
Generating 10 million RSA 2048 bit keypairs isn't free, and you still have to maintain a significant set of network flows and perform decryption against them.
[0]https://github.com/telehash/telehash.org/blob/master/protoco...
Generating 10 million RSA 2048 bit keypairs isn't free, and you still have to maintain a significant set of network flows and perform decryption against them.
[0]https://github.com/telehash/telehash.org/blob/master/protoco...
Outside of this, what are the relationships between this BitTorrent's DHT and telehash? Are they covering the same ground but not necessarily compatible? Encrypted, distributed P2P traffic with discoverability would help a number of projects -- it would be great not to have to "pick a side" already.
Jeepers, if I'd actually read the last slide, I'd have seen that the paper explicitly mentioned telehash.org with the sha1(ip:port) proposition.
That was v1 of the Telehash spec, and plenty of intervening feedback (along the lines of nly's comments) in the last three years has lead to the current v2 draft.
Telehash aims to be a bit more generalized than BitTorrent, stripping out the file seeking behavior and focusing on the lower level mesh network overlay. BT-like behavior (or other application patterns) can be implemented via "channels" between nodes.
Telehash also switched from sha1 to sha256 (and thus from 160bit to 256bit nodeIDs), along with NIST and now Microsoft (see wikipedia). That aside, sha(address) versus sha(pubkey) isn't really a surmountable difference. You're doomed to "pick a side" here. :)
But Telehash is extremely non-controversial and boring, otherwise. Within this Kademlia-based framework, it's following the best practices of the latest TLS specs (RSA + ECDHE + AES [GCM, I think]), subtracting X.509.
The spec is public domain, and most of the current alpha implementations (7 of which are interoperating at last count), have been MIT licensed since the get go.
whew That sums it all up, I think.
That was v1 of the Telehash spec, and plenty of intervening feedback (along the lines of nly's comments) in the last three years has lead to the current v2 draft.
Telehash aims to be a bit more generalized than BitTorrent, stripping out the file seeking behavior and focusing on the lower level mesh network overlay. BT-like behavior (or other application patterns) can be implemented via "channels" between nodes.
Telehash also switched from sha1 to sha256 (and thus from 160bit to 256bit nodeIDs), along with NIST and now Microsoft (see wikipedia). That aside, sha(address) versus sha(pubkey) isn't really a surmountable difference. You're doomed to "pick a side" here. :)
But Telehash is extremely non-controversial and boring, otherwise. Within this Kademlia-based framework, it's following the best practices of the latest TLS specs (RSA + ECDHE + AES [GCM, I think]), subtracting X.509.
The spec is public domain, and most of the current alpha implementations (7 of which are interoperating at last count), have been MIT licensed since the get go.
whew That sums it all up, I think.
Yeah I'm aware of Telehash. Any idea how large the current DHT is?
Very small, as the second draft of the protocol is still in heavy revision.
Not sure if you'll see this now. Having looked over TeleHash 2, I have quite a few concerns about the complexity of the protocol. It's hard to tell what is being accomplished at each step and why. The way things are composed and layered definitely needs explanation. For instance, signatures are encrypted, and there's a mix of RSA and EC, why?
My cousin post in this larger thread might answer most of your questions.
Quick answers: the RSA + EC mix roughly mirrors TLS. The signature encryption is a recent update to make network analysis harder on passive listeners.
Most of the implementors are hanging out in XMPP:[email protected] until Telehash-based chat is stable (a month maybe?). We'd love to get more feedback.
Quick answers: the RSA + EC mix roughly mirrors TLS. The signature encryption is a recent update to make network analysis harder on passive listeners.
Most of the implementors are hanging out in XMPP:[email protected] until Telehash-based chat is stable (a month maybe?). We'd love to get more feedback.
sha1(ip+port) is tricky in the presence of NAT, since different peers may see your packets as coming from different ip+port pairs.
Not really. DHT servers must accept unsolicited incoming connections, which requires port forwarding. The problem as I see it is really dynamic IPs.
In any case, this wouldn't stop an adversary acquiring a lot of IP addresses for a short period of time. Bitcoin is immune to these kinds of attacks because it requires proof of work, which you can't just fake.
In any case, this wouldn't stop an adversary acquiring a lot of IP addresses for a short period of time. Bitcoin is immune to these kinds of attacks because it requires proof of work, which you can't just fake.
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 ?
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 ?
I applied for BTSync API and ended up in my inbox that same night. You may want to ping them in their forum if you aren't receiving one...
This was meant to be in response to the earlier comment by ritonlajoie. Sorry about confusion posting this on its own...
Question for the HN crowd: how does one can use DHT/trackerless to not only distribute files, but updates to them too?
Sort of like an ever continuing magnet link if you will?
Sort of like an ever continuing magnet link if you will?
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
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
Yeah but then you end up changing the info hash, and thus your magnet is changed.
What I'm trying to do is to basically embed the magnet link in my program and sort of having it self check itself for updates. It that makes sense :)
What I'm trying to do is to basically embed the magnet link in my program and sort of having it self check itself for updates. It that makes sense :)
Whether it's helpful for any current efforts using BT infrastructure, there's been a lot of work on this problem since Van Jacobsen sketched the outlines a few years ago:
http://named-data.net/
http://named-data.net/
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.
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.
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...