BitTorrent secures and open-sources DHT bootstrap server • Hacker News Board

Re: BitTorrent secures and open-sources DHT bootstrap server

#21

Post by dvanduzer » Sun, Dec 22, 2013, 9:14 PM UTC

smcnally wrote: post #18

dvanduzer wrote: post #15

Earlier quoted context omitted.

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...

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.

Re: BitTorrent secures and open-sources DHT bootstrap server

#22

Post by dvanduzer » Sun, Dec 22, 2013, 9:18 PM UTC

astro1138 wrote: post #20

oakwhiz wrote: post #7

Earlier quoted context omitted.

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…

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

Re: BitTorrent secures and open-sources DHT bootstrap server

#23

Post by steeve » Mon, Dec 23, 2013, 12:33 AM UTC

fredsted wrote: post #10

steeve wrote: post #8

Earlier quoted context omitted.

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 :)

Correct me if I'm wrong, but isn't the magnet link a hash of the files? Then it would not be possible to change the files without changing the link.

it is exactly that, unfortunately...

Re: BitTorrent secures and open-sources DHT bootstrap server

#24

Post by nly » Mon, Dec 23, 2013, 1:34 AM UTC

astro1138 wrote: post #20

oakwhiz wrote: post #7

Earlier quoted context omitted.

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…

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

I'll be at 30 ;)

Re: BitTorrent secures and open-sources DHT bootstrap server

#25

Post by nly » Mon, Dec 23, 2013, 3:22 AM UTC

dvanduzer wrote: post #19

nly wrote: post #17

Earlier quoted context omitted.

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?

Re: BitTorrent secures and open-sources DHT bootstrap server

#26

Post by dvanduzer » Mon, Dec 23, 2013, 4:22 AM UTC

nly wrote: post #25

dvanduzer wrote: post #19

Earlier quoted context omitted.

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:theroom@conference.jabber.org until Telehash-based chat is stable (a month maybe?). We'd love to get more feedback.