Theseus DHT Protocol (2018)
wootfish.github.io
wootfish.github.io
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-system-for-pr...
I'm curious why the OP is interested in this project, or if anyone else has any interesting DHT tools they want to share?
[1]: https://www.google.com/search?&q=Theseus+dht+protocol+%22aud...
[2]: https://scholar.google.com/scholar?q=theseus+dht+protocol
This is at best an obfuscation attempt to make fingerprinting more expensive, just like BitTorrent protocol encryption[3].
† I Am Not A Cryptographer
[0] https://support.signal.org/hc/en-us/articles/360007060632-Wh...
[1] https://en.wikipedia.org/wiki/Certificate_authority
[2] https://en.wikipedia.org/wiki/Web_of_trust
[3] https://en.wikipedia.org/wiki/BitTorrent_protocol_encryption
You're correct that part of the assumption inherent in end-to-end encryption is that you've got the other end right; otherwise, MitM attacks become possible. To prevent this, Social apps like Signal (also WhatsApp and many others) give you, roughly speaking, a way of confirming that both endpoints have negotiated the same secure channel. Less-social web apps use PKI. In both these cases, the design makes sense because you care who the other endpoint is. Their identity is meaningful to you outside of the context of the protocol.
In the peer-to-peer context, though, this identity information is mostly meaningless. I think, as long as there are no "network admins" or similarly privileged identities worth claiming, it's less important to certify identities up-front (what would even be a reasonable standard for accepting them?) and it's more important to be able to persist them. You want to make sure you're still talking to the same person you were talking to last time, whoever they are. This is what the PSKs are meant to accomplish (though they are not the only possible solution here).
This is technically still MitM'able, but only if you catch two parties on their very first connection; after that, they have a shared secret, and you should be locked out. Technically this falls slightly short of the ultimate goal of end-to-end encryption, but I still think it's a good fit for this context.
I went into this in (much) more detail in this old blog post: https://eli.sohl.com/2017/06/09/message-encryption-in-theseu...
Ah, haven't realised it was Trust On First Use (TOFU)--neat!
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)?
The "best" resources I know of are the ones I cited in that post, though do bear in mind it's a few years old. That said, I did want to make sure you didn't miss this companion piece: https://eli.sohl.com/2020/06/05/dht-size-estimation.html which is applicable to detecting (and - conjecturally - responding to) Sybil attacks.
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
This.
And it should have been a design requirement for every protocol on the internet since day one.
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.
While this is not a universally useful property, it can be valuable in situations where even being able to detect a device is using a particular protocol is a problem. A good example is using an anonymization network like Tor in a repressive country like China. Even if your data is protected by Tor, you probably don't want the authorities to know you're using Tor at all.
As you said, one of the biggest problems with this is that even if the protocol itself is perfect, it's not worth much if the network participants are known and communicating with them is itself evidence you're using the protocol. The solution to that would either be making the participants non-public and hard to discover (so an observer doesn't know you're talking to a network participant) or having participants do a lot of things other than participate in the network you're trying to hide. Tor for example takes the former approach with non-advertised "bridges" that you have to know about via some out of band method (e.g. someone emails one to you).
In practice, this indistinguishably property is becoming less useful even when it works given the ubiquity of "normal" encrypted protocols like SSL/TLS. Arguably just using TLS is far better than trying to look like random noise even if you're trying to hide, since random noise on a network is much less common than TLS and probably more of a red flag these days.
The tricky thing about baking TLS in at the protocol level is that it brings its baggage with it. This is not necessarily a bad thing, but it makes the design more complex to reason about. In particular, it is arguably overkill when you're not planning on using certificates, as is the case here. Just compare the number of steps here: https://tls13.xargs.org/ to any of the patterns here: http://www.noiseprotocol.org/noise.html#interactive-handshak...
Another thing worth mentioning regarding indistinguishability from randomness is the impact of metadata. Even if the bytes you send on the wire look meaningless, there's still the size of the message, the spacing between messages, the time of day, etc. Any of these channels can carry signal, and it is very hard, if not impossible, to get rid of those signals completely.
That said, I still think the original goal of indistinguishability is worthwhile, because if you can force the passive adversary to move from perfectly accurate methods (e.g. fingerprinting message contents) to imperfect ones (e.g. guessing the protocol from message timing), that seems like a win to me.
> Release date: 4/20/2018
> Revision date: 10/8/2018
Would be nice to get a (2018) in the title.
Digging into the GitHub repo: “The implementation is not yet complete.”
The most common encrypted protocols advertise the cipher suite they're using, so there is little value in concealing the format of the keys being exchanged. And protocols trying to hide their existence entirely are pretty uncommon.
The fact that Tor is mentioned would suggest that you have to add that to be secure.
For users in extreme circumstances, Tor gets them a lot, but it also adds a lot of overhead; you'd want to avoid it if you don't need it, not just for your own sake but also for the sake of Tor's finite bandwidth. There is a lot to be said for having a feature like Tor be supported-but-optional, opt-in, and interoperable with users who are not on Tor.
I did consider the idea of allowing Tor hidden service addresses as an alternative identifier to IPs, though that idea comes with its own compromises: you'd only be able to talk to other Tor peers, for instance, or, alternately, every peer would have to be on Tor.
The latter case is obviously a non-option. The former case would kind of work, but the Tor-hidden-service peers' effective network size would be much smaller (since they can only talk to Tor peers) and thus easier to compromise. This is obviously bad - users in need of greater security would end up in a less secure version of the network - and if this subsection gets owned, that could have a second-order impact on the network's overall resilience.
IPFS
Stop using sessionful protocols for DHTs. It. does. not. work.
For comparison, the BitTorrent DHT has 20 MILLION nodes and works fantastically.