This is an old revision of the document!
Table of Contents
Sharing Tox ID's
WARNING: If you are looking for shorter and more memorable IDs, remember that the relation between any kind of names and Tox IDs is neither protected nor ensured by the Tox protocol. By the nature of name services (when you e.g. use a ToxDNS) you put full trust into unverified third party data and also get that data over a different, insecure protocol. The safest way to share your Tox ID is by giving your Tox ID (not ToxDNS name or whatever) directly over a secure channel. The only reliable registry with names of your contacts is your personal contact list. To make it safe you also must set your own permanent labels (names/aliases) on the contacts in the list. The ability of contacts to freely change their display names in your contact list is totally insecure. At least some clients offer unsafe contact list as the default, this looks innocent but is a serious security flaw.
Below are some of the ways to share Tox ID's and their benefits and drawbacks. This is an attempt to address the different things that can come into play when initially authenticating a Tox user.
In Person, Manual Verification
In this scenario, 2 people with Tox ID's meet in person (or using any other secure channel), and exchange the ID's in front of each other, enter the ID's manually, and send a test message. This is equivalent to manually verifying a fingerprint in OTR.
Using Tox URIs to ease entering Tox IDs, Manual Out-Of-Channel Verification
In this scenario, a user creates a Tox URI which is used to help fill out the Add Friend form in a Tox client supporting Tox URI feature and registered in your system as Tox URI handler application. The security of this method depends on the security of the method used to transfer the Tox URI. See Also.
Using ToxDNS Services to ease entering Tox IDs
ToxDNS services allow users to register an email-like username for their Tox ID, so that users could use short and memorable usernames, as clients can look up Tox ID based on the username. Note that you must fully trust ToxDNS service to return your and not someone else's Tox ID for your registered username. ToxDNS services might also use insecure protocols.
Because of that, you can't be 100% sure that that your ToxDNS username maps to the Tox ID you registered. A meeting in person with the other party and verifying the Tox IDs can confirm this. To the contrary, without such verification even if sending a test message shows that messages are going to the intended recipient at that particular moment, this can not detect if your messages are being relayed by a malicious third party - only the actual checking of the Tox IDs of each other (not by sending them via Tox itself!) can tell. This is not a Tox limitation but an inherent property of remote communication. See Also.
Useful resources for verification of regular OTR Identities
I'm going to use this information to come up with the content of this page. The principles need to be adapted for Tox but some of them still apply, especially when using ToxDNS.
EFF's How To Use OTR on Window's Guide See sections “Chatting Securely” to “Working with Other Software.”
Cypherpunks guide to Authentication The most complete guide to the traditional methods of verifying OTR fingerprints with libpurple.
Adium Off-The-Record Documentation Pretty decent glossary.