4 ms·
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 ran
by oakwhiz 13y ago
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.
- jamii 13y agosha1(ip+port) is tricky in the presence of NAT, since different peers may see your packets as coming from different ip+port pairs.
- nly 13y agoNot 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.
- nly 13y ago> 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?
- dvanduzer 13y agoThat'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/protocol.md https://github.com/telehash/telehash.org/blob/master/protoco...
- nly 13y agoYeah I'm aware of Telehash. Any idea how large the current DHT is?
- dvanduzer 13y agoVery small, as the second draft of the protocol is still in heavy revision.
- nly 13y agoNot 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?
- dvanduzer 13y agoMy 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:theroom@conference.jabber.org until Telehash-based chat is stable (a month maybe?). We'd love to get more feedback.
- smcnally 13y ago
- astro1138 13y agoHi, 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 https://github.com/rtreffer/dht