

Project Tox: The Crypto IM & Video Conferencing Program - Plexion

A group of people begun work on a program that is a free alternative to Skype; but with some crypto added. It uses DHT instead of central servers, and we&#x27;re looking for help.<p>It&#x27;s on GitHub: https:&#x2F;&#x2F;github.com&#x2F;irungentoo&#x2F;ProjectTox-Core<p>Help is much needed, and welcome.
======
Zaphot
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! :)

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

------
schrodingersCat
Best of luck to you. This a very ambitious and brave project.

