Distributed FOSS secure messenger with audio and video chat capabilities
Tox began a few years ago, in the wake of Edward Snowden’s leaks regarding NSA spying activity. The idea was to create an instant messaging protocol that ran without any kind of central servers. The system would be distributed, peer-to-peer, and encrypted end-to-end, with no way to disable any of the encryption features; at the same time, the protocol would be easily usable by the layperson with no practical knowledge of cryptography or distributed systems. Work began during the Summer of 2013 by a single anonymous developer (who continues, to this day, to remain anonymous). This lone developer put together a library implementing the Tox protocol. The library provides all of the messaging and encryption facilities, and is completely decoupled from any user-interface; for an end-user to make use of Tox, they need a Tox client. Fast-forward a few years to today, and there exist several independent Tox client projects, and the original Tox core library implementation is nearing completion (in terms of features). Tox (both core and clients) has thousands of users, hundreds of contributors, and the project shows no sign of slowing down. Recently, a group of some of the project’s major contributors have formed The Tox Project, an organization built around the protection, promotion, and advancement of Tox and its development.
Tox protects your privacy by:
Tox makes no attempt to cloak your IP address when communicating with friends, as the whole point of a peer-to-peer network is to connect you directly to your friends. A workaround does exist in the form of tunneling your Tox connections through Tor. However, a non-friend user cannot discover your IP address using only a Tox ID; your IP address will only be discernible when you accept/send a friend request, and add a user to your contacts list.
No. That said, in some situations a client will choose to use publicly listed bootstrap nodes to find their way into the DHT.
Tox uses the cryptographic primitives present in the NaCl crypto library, via libsodium. Specifically, Tox employs curve25519 for its key exchanges, xsalsa20 for symmetric encryption, and poly1305 for MACs.
Tox does not make use of SIP.
Look in the profile or settings panel of your client to get your Tox ID which should look something like:
Give yours to your friend and get your friend to add it. That’s it.
If you want a shorter and more memorable ID, you can use a service like ToxMe, that maps an email-address-style username to a Tox ID. However, an individual concerned about their security should avoid using these services where possible. Unfortunately, the cost of this convenient name-to-Tox ID mapping is a loss of decentralization. You must trust that the entity running the service is serving you (and others looking for you) accurate information. If you’re not careful, you may be subject to MITM attacks.
Tox generates a temporary public/private key pair used to make connections to non-friend peers in the DHT. Onion routing is used to store and locate Tox IDs, to make it more difficult to, for example, associate Alice and Bob together by who they are looking for in the network.
Assuming that Toxcore has already been built, cd to
./DHT_bootstrap ADDRESS PORT KEY
Change ADDRESS, PORT, and KEY to that of any active DHT node.
Toxcore also has a daemonized version of the bootstrap node code wish can be used on SystemV init or systemd init systems. You first need to configure tox to build the bootstrap node executable. Run the configure script with
as an argument. The tox_bootstrap_daemon executable will be placed in
, so grab a copy from there and place it where you want the daemon to run from.
Note that the following instructions might be out of date and it’s preferable to read the README.md file maintained by the daemon developer.
Next we need to configure
Set the NAME, USER, CFG, PIDFILE and SCRIPTNAME arguments as per your installation.
|NAME||Name of the executable (default is the tox_bootstrap_daemon)|
|USER||Name of the user the daemon will run as (e.g. tox)|
|CFG||Location of configuration file|
|PIDFILE||Where to create the pid file for the daemon|
|SCRIPTNAME||Path to the tox_bootstrap_daemon.sh (used to change name of the script)|
There are a few other options generated by a combination of these items, and you may wish to customize them for your needs.
Now we need to configure the conf file that the daemon uses, located in
At minimum you need to set the keys_file_path, pid_file_path and add some bootstrap nodes.
|keys_file_path||The path to your keys file that will store the keypair for your daemon|
|pid_file_path||The path to the pid file and should be set based on what you chose for PIDFILE earlier|
Place the daemon script in
and rebuild the service list.
Finally, start the service!
ToxDNS is a tox ID-to-name mapping service. It allows users to shorten their regular, somewhat long, Tox IDs, with short and readable IDs, that closely resemble the format of an email address. An example of a ToxDNS service in use is email@example.com, Which when added, resolves to the full ID (
ToxDNS servers are federated, they are each run by their individual operators and their databases are stored online. This can, but doesn’t necessarily, compromise your privacy, but really it’s simple to minimize the risk so that it’s nearly nonexistent.
Some people have some concerns about how ToxDNS services could be used maliciously, mismanaged, or exploited as a single point of failure in order to deny a person the ability to look up the ID they want. Hopefully I can address those concerns here.
Impersonating a user(MITM) by switching the Tox ID associated with the username: If someone compromised your account on a ToxDNS Service or a server hosting ToxDNS records, they might be able to replace the Tox ID associated with the username. New users looking up a Tox ID using the compromised username would be directed to the wrong Tox ID. To minimize the chance of such a thing occurring, use a long, unique, random password for your ToxDNS account, and set the ID to be unchangable if the server supports it. This will not connect you with your intended friend and it does not give anyone access to your private key or any current or previous chat sessions keys.
Malicious Service Operator gathering metadata on Tox ID’s as they are registered: A malicious site operator could keep some information about the users of the ToxDNS service as they register by retrieving that information from their browsing session. This could be used to correlate the ID to the IP address they used to register the ID with the ID and the email. If this concerns you, then sign up for the service via a reliable Onion Router for browsing the Web like Tor.
Denial of Service against a ToxDNS Service: If someone denies users access to the ToxDNS service they wish to use to lookup an ID, then they will not be able to look up ID’s at that service. If this is a concern, you might join multiple ToxDNS services, host your own ToxDNS service, or distribute your whole Tox ID in text form or using a ”tox:” link.
It should be noted that none of these area actually problems with ToxDNS itself. The first two are malicious activities that could be undertaken on a server, the third is just somebody taking a site down or blocking access to a site.
it will be available for all platforms including Windows and Mac apart from Linux.
Tox is still under construction.