Project Tox: The Crypto IM & Video Conferencing Program
3 comments
Did you guys think about how to prevent man-in-the-middle, Eclipse, Sybil and Identity attacks against your DHT?
These kind of attacks don't matter much in bittorrent's kademlia-style dht since it is not necessary to be able to reach every peer.
After all it doesn't matter which peer sends you the slice, with the root hash you can verify the validity of every slice.
But for a Skype replacement it is important to be able to reach every peer even if a large amount of peers are malicious (which is a plausible scenario since it doesn't cost much to create an id and there are certainly some people that want to prevent a system like this ;)). (Note: Hole Punching is not always possible so you also need a relay functionality)
But for example: Who prevents me from just creating a lot of Id's that are (in the xor metric) next to Alice and isolate her in the DHT? Since there is no mutual authentication and blocking a given IP is not always a good idea (relaying) how do you prevent user-add-spamming attacks.
How do you want to implement a safe look up service on top of a DHT and prevent ending up with 200 Alices (how can a user know which one is the right Alice). Requiring a user to type in a 32 byte key to add a friend may be ok for people like us but not for the casual user.
I didn't look at your code, but is your DHT superpeered like the Skype DHT was before they moved to their own servers? Otherwise you could get serious problems with churn and Kademlia has shown to have more problems with churn than other DHT designs anyway.
There are some good papers about these types attacks and appropriate preventions. Some propose to work with social graphs to detect malicious nodes, others try to limit the attack feasibility by requiring a proof of work for every DHT operation but that's still an active research topic and not really settled. So doing a project like this without at least one central instance and being considered attack resistant is not really feasible imho.
The easiest way to make your DHT attack resistant is to build one central ca server that creates the user certificates and each node checks if the cert is valid before communicating with another node. Users would only have to connect to the ca once, in order to get a cert, afterwards they can participate in the DHT without contacting any central instance.
If you create a system like that you should think a few weeks about the general design before writing any code. Especially when it comes to crypto, there are a lot of pitfalls. It's best to first write a complete technical report or paper, get it reviewed from some people, and then write the code.
Anyway there is a big need for an easy to use, secure and open source communication system. But it must be easy to use for everybody (even my grandma). Convenience is the main point why normal people don't use crypto yet. 'Why Jonny can't encrypt' is a nice paper about this topic.
But please continue your work, privacy is an important topic! :)
But for a Skype replacement it is important to be able to reach every peer even if a large amount of peers are malicious (which is a plausible scenario since it doesn't cost much to create an id and there are certainly some people that want to prevent a system like this ;)). (Note: Hole Punching is not always possible so you also need a relay functionality)
But for example: Who prevents me from just creating a lot of Id's that are (in the xor metric) next to Alice and isolate her in the DHT? Since there is no mutual authentication and blocking a given IP is not always a good idea (relaying) how do you prevent user-add-spamming attacks.
How do you want to implement a safe look up service on top of a DHT and prevent ending up with 200 Alices (how can a user know which one is the right Alice). Requiring a user to type in a 32 byte key to add a friend may be ok for people like us but not for the casual user.
I didn't look at your code, but is your DHT superpeered like the Skype DHT was before they moved to their own servers? Otherwise you could get serious problems with churn and Kademlia has shown to have more problems with churn than other DHT designs anyway.
There are some good papers about these types attacks and appropriate preventions. Some propose to work with social graphs to detect malicious nodes, others try to limit the attack feasibility by requiring a proof of work for every DHT operation but that's still an active research topic and not really settled. So doing a project like this without at least one central instance and being considered attack resistant is not really feasible imho.
The easiest way to make your DHT attack resistant is to build one central ca server that creates the user certificates and each node checks if the cert is valid before communicating with another node. Users would only have to connect to the ca once, in order to get a cert, afterwards they can participate in the DHT without contacting any central instance.
If you create a system like that you should think a few weeks about the general design before writing any code. Especially when it comes to crypto, there are a lot of pitfalls. It's best to first write a complete technical report or paper, get it reviewed from some people, and then write the code.
Anyway there is a big need for an easy to use, secure and open source communication system. But it must be easy to use for everybody (even my grandma). Convenience is the main point why normal people don't use crypto yet. 'Why Jonny can't encrypt' is a nice paper about this topic.
But please continue your work, privacy is an important topic! :)
If anyone was wondering, "why not just use Ekiga or something similar?" the point of this is to be peer-to-peer. This caused a lot of confusion at first.
Best of luck to you. This a very ambitious and brave project.
It's on GitHub: https://github.com/irungentoo/ProjectTox-Core
Help is much needed, and welcome.