Tagged with: [ dht ] [ encryption ] [ json ] [ kademlia ] [ p2p ] [ telehash ]
In the current day and age, using a plain HTTPS connection might not be the most secure way to communicate anymore. Sure, for your purposes and goals we can assume that this communication is safe enough, but cracks are appearing in the security, and we might need to move to better, more secure ways in maybe a shorter period than anyone expected. But how do we do this? We are not crypto-experts, and you probably have no idea how HTTPS works to begin with. Should we find ourselves a secure way to encrypt our data? Should we “invent” new methods that look safe, just because it’s too complex to explain what’s going on?
Obviously, this is not the way forward. What IS the way forward, are projects like telehash. This is a peer to peer network (there is no central server regulating things) that allow you to communicate with other peers in a fully encrypted way. Fortunately, you as an application developer do not need any knowledge in this setup. Everything will be done automatically so you only have to focus on your application.
What is telehash?
Telehash is a peer to peer (p2p) network created by the inventor of Jabber: Jeremie Miller. The benefit of using a p2p network is that there is no central server which you need to register yourself or need to connect to. This means that bringing down a p2p network is hard - to say the least. Telehash is based on the kademlia distributed hash table (DHT) system. It boils down to the fact that every node knows a few other nodes. When you want to contact node “Z”, and you only are connected to node “B”, you will ask node “B” if he knows about node “Z”. Either the answer will be a yes or no. When node “B” does not know about node “Z”, it will however, know about nodes who might now more info (just like: i don’t know this guy, but i know somebody who might know).
This isn’t a complete random process: a node will only return nodes that are “closer” to the actual node you are looking for. So, node “B” will return node “K”, and node “K” will return node “O”, but not node “E”. This is due to the fact that node “O” is closer to node “Z” than node “E” is. It turns out that with just a few questions asked, you could pretty much find every node in such a system pretty quickly, even if there are millions of nodes inside the p2p network.
In telehash, we obviously don’t use the alphabet for node names, but we use 160bit long strings. These strings are automatically generated by telehash. In more detail: these nodenames are sha256 hashes of a generated public RSA key that will be generated when telehash runs for the first time on that particular system (it’s possible to have more telehash nodes running on one server though, as long as they all have a different key, and thus nodename).
Telehash consists of 2 parts: the most important part is the so-called “switch”. This is the part of telehash that takes care of finding the p2p network, connecting to new nodes, seeking other nodes, asking and answering questions from other nodes.
The second part is your application that will communicate with other applications. In a sense, your application just does the same communication like it would over a standard TCP port: you open a so-called channel to another node, or another node opens a channel to you, and you can communicate. Telehash takes care of finding that node, and encrypting all your data.
Using a p2p network is one thing, but how do we do it in a safe and secure manner? For this, telehash uses different encryption algorithms and techniques. Even if one of those algorithms would be cracked, there is still another layer that must be cracked too in order to reach your application data (and to be very paranoid, you could encrypt this on your application-layer as well).
The key foundation of telehash encryption is ECC - elliptic curve cryptography. It’s a more advanced way of public key cryptography than for instance RSA is, even though RSA plays a big part in telehash as well. There are all kind of different ways the telehash data packets are encrypted and signed and secured in order to make sure that only those two nodes can safely communicate with each other. Never is a key used more than once: every node connects to other nodes every time with different keys so even when a key is compromised, the rest of the nodes are still safe.
Writing your application
Depending on the language you are using,there are already libraries that allow your application to use telehash. This way, you can focus on opening channels to other nodes, and sending and receiving data. Let telehash worry about everything else.
Even though this all sound promising, there is still a lot of work that needs to be done. The specifications on telehash is are still in draft and can change but we are getting to a more and more stable network. If you like to help out, like writing clients, applications, testing etc, don’t hesitate to take a look at the git repo.