Live data from Hacker News

Theseus DHT Protocol (2018)

wootfish.github.io

11–20 of 43 posts

Re: Theseus DHT Protocol (2018)

#11
post #7
post #2

Does it allow someone with knowledge of a key to find the IP addresses of other people interested in that key? Because if yes, the other security guarantees are not all that interesting. The fact that Tor is mentioned would suggest that you have to add that to be secure.

I just had a brief read of the protocol but my understanding is yes, there is nothing like onion routing or similar that could disguise to a peer that is serving the data that the requester is indeed the one who is interested in it.

[deleted]

Re: Theseus DHT Protocol (2018)

#12
post #6

Oooh interesting! I've been reading up on DHT's for the first time recently (I'm very late to the party). It looks like the original inspiration was an anti-censorship network for sharing/providing scientific papers: https://eli.sohl.com/2017/02/17/theseus-robust-system-for-pr... But as another poster noted, the project seems to be defunct do it being a solo effort: https://eli.sohl.com/2017/02/17/theseus-robust-syst…

bittorrent-dht: https://github.com/webtorrent/bittorrent-dht (JavaScript implementation used by WebTorrent)

Re: Theseus DHT Protocol (2018)

#14
post #9

> To a passive observer, all Theseus DHT protocol traffic is indistinguishable from random noise. This. And it should have been a design requirement for every protocol on the internet since day one.

So, identifying this protocol must be trivial: it's the one that looks like random noise.

Re: Theseus DHT Protocol (2018)

#15
post #9

> To a passive observer, all Theseus DHT protocol traffic is indistinguishable from random noise. This. And it should have been a design requirement for every protocol on the internet since day one.

It's a cool property for sure, but in reality it's pretty difficult to implement, especially if you want a protocol that's extensible, interoperable, or allows open communication. At minimum, you're probably going to have to assume any participants trying to speak the protocol to each other have pre-shared cryptographic keys and/or protocol parameters.

Even a protocol like Wireguard for example, which does hardcode protocol parameters and requires the client to know the server's public key in advance, is not designed to be indistinguishable from random noise. You can certainly do it, but you lose a lot of other properties that are arguably more important to protocol design than indistinguishably.

Re: Theseus DHT Protocol (2018)

#16
This seems to be ~4 years old. Have any cryptographers reviewed / audited this protocol in the interim? A quick google search comes up empty [1], and google scholar doesn't show anything [2].

[1]: https://www.google.com/search?&q=Theseus+dht+protocol+%22aud...

[2]: https://scholar.google.com/scholar?q=theseus+dht+protocol

Re: Theseus DHT Protocol (2018)

#17
post #7
post #2

Does it allow someone with knowledge of a key to find the IP addresses of other people interested in that key? Because if yes, the other security guarantees are not all that interesting. The fact that Tor is mentioned would suggest that you have to add that to be secure.

I just had a brief read of the protocol but my understanding is yes, there is nothing like onion routing or similar that could disguise to a peer that is serving the data that the requester is indeed the one who is interested in it.

Maybe this is also why they underline in the preamble that it is suitable for running over Tor.

Re: Theseus DHT Protocol (2018)

#19
Cool project, which lead me to this post: https://eli.sohl.com/2020/06/10/sybil-defense.html

I'm in this space right now (Sybil-resistant DHTs) for an identity project and finding things like this is absolute gold for me. Is there a good place to find more articles on modern sybil protection mechanisms (other than the proof-of-whatever blockchain bs)?

Re: Theseus DHT Protocol (2018)

#20
Anyone here an expert on DHTs, or maybe an enthusiast?

Back in 2018 when I was designing the Intercoin Protocol (which we now call the Intercloud) I met with Petar Maymounkov, who invented Kademlia in the early 2000s. Dude used to teach at NYU (my old school) so I emailed him and took him to Olive Tree Cafe — wound up asking him a bunch of questions and learning a lot.

Anyway, I have a question about all this. Consensus is an expensive operation and th reason Blockchains are slow is because they run fu network consensus cor every block. In Intercloud, we run network-wide consensus only occasionally, and mostly to update a provably random seed (by combining input from many different nodes). This serves as a seed for a random oracle for the network.

Now, that oracle is used during “shuffling”. I think we may have originally got the idea from the SAFE project. What happens is that, every so often, swarms of nodes are shuffled and nodes are reassigned to other swarms. So although they may pick their original swarm, they have no control over what future swarms they will be in, because it is effectively impossible for then to predict, let alone control, the random oracle and hashes of activity from neighboring swarms. Being off by a single bit throws off any of their well-laid plans.

Shuffling is necessary to break up swarms that have been corrupted, overrun by dishonest nodes sybil attacks, or just unable to reach consensus due to unavailability.

So most of these DHT issues go away. However, encryption is still a very good idea.

Another GREAT idea is what SAFE pioneered - removing the IP addresses from responses after the first hop. Because otherwise it is trivial to DDOS a network or a subset of it.

PS: last year I interviewed Ian Clarke (creator of Freenet) about this stuff https://m.youtube.com/watch?v=JWrRqUkJpMQ

Post reply on HN