TOX: What happened in the project for six months

Many probably already heard about Tox - this is the instant messenger that should replace Skype, providing the same functionality as its proprietary counterpart, presenting such useful things as: Encryption of everything and everything, lack of surveillance, lack of advertising, decentralization.

It may seem that the project is deadly developing too slowly, but in fact, under its hood (in the core), there have been huge changes that are worth highlighting.

Tox, like most software, is now divided into core and shell, and usually, the core is developed by some people, and the shell is completely different, the speed of development and implementation of new functions are not always the same quickly in both parts (Core / Shell)
')
In the last post, we tested Tox audience habras (and sent my test ID to spam sheets) .
But from this point on, changes have occurred, some of which can already be “touched,” and some can only be read and helped to be realized in the shell.

Anonymity

Protection against identification by adding to friends

Tox is an instant messenger based on a DHT network, which means that you and your IP address are visible to the whole world.
In the Tox world, clients identify each other based on the keys generated when they first started, obviously, there was a problem of direct communication ID = IP address = physical person = repression .

To solve this problem, apply the onion routing, which I mentioned in the last post.
The principle of its work is as follows:
Alice wants to add Bob as a friend for further communication.
1) She chooses random three peers in the Tox network and announces herself by onion routing rules (the first node knows Alice’s address and ID, the second node knows only the address of the first node and Alice’s ID, the third node knows the ID and the IP address of the second node respectively) (Bob does the same when starting the client, choosing a sequence of three nodes)

2) She looks for DHT nodes that know about the existence of Bob and sends them a message about adding to friends

3) After receiving the authorization request, it is transmitted to a group of peers who know about the bean, and the authorization request passes through the following random three nodes selected by Bob.

4) After authorization is received, the process is repeated using new random nodes to send confirmation of adding as a friend.

5) A direct connection is established in which Bob Alice’s IP addresses are already visible and vice versa.

User Authentication Based on Data Accumulation

In the DHT network, usually (Bittorrent / Kademlia) when you first connect to the network, random identifiers are generated that do not change when the IP address is changed .
Obviously, in the framework of a secure messenger - this is a problem.

It is solved in the following way:
1) When first started, a long-acting ID / Key is generated.

2) Based on the primary keys, each time the IP address is changed, new ID / Key are generated (they also change after a random period of time)

But how will Alice find Bob if she can't find him using the old key in the DHT?

Alice and Bob are friends, they generated temporary keys and connected to the DHT network.
Bob finds random three nodes (A, B, C)
Bob finds the closest node that is closest to him (D)

Bob creates onion routing (the packet will follow through nodes A, B, C and the output point of the packet will be node D)
In place of his key and ping_id address, he announces all zeros.
Bob will continue to build the chain until he finds the node that is closest to him based on his real public key.

As soon as such a node is found, a request will be sent to it with valid ping_id data (not its own, but any of nodes A, B, C) - this node will be the final node which will further announce Bob and be responsible for it in the network performing the role of node D

Bob will ask this node to keep in memory information about it to interact with the network.

Meanwhile, Alice is looking for the closest node to Bob, she uses the temporary keys and ID, as soon as she receives a response in the form of ping_id = 0, she sends the data to this node and asks to transfer it to Bob, transferring her temporary ID to the DHT network.

Bob finds it on the network, based on her temporary ID, a direct connection is established.

Thus, it is impossible to find out the IP address of a bean and Alice until they are added as friends to each other, so it is impossible to associate a TOX ID and a DHT ID (without adding as friends) with a real IP address.

PS Naturally, at each stage the packages are encrypted and protected from falsification.

Fighting NAT admins and firewalls

If you remember, Skype bypasses firewalls using super nodes and using standard ports, TOX will also be able to do that.
- Work through port 80/443
- Find super-nodes or be them.
- Use UDP / TCP depending on the environment

Tox mainly uses UDP (for NAT punching), but if the UDP traffic is blocked by the security settings, TOX will do the following:

1) Alice uses Tox on a connection that only allows TCP connections, she generates temporary public keys and connects to nodes for initialization.

2) After receiving data about the network from the initialization nodes, it selects a certain number of random nodes that are super nodes

3) Using a super-node onion-based routing via TCP, it can send authorization requests or inform its contact list about its online status using a temporary public key.

4) Bob receives the packet through onion-based routing from Alice, who informs him of which nodes she is connected to via DHT using the temporary public key.

5) Bob connects to the same nodes as Alice.

6) This connection is used to transmit both messages and A / V traffic.

7) If a node goes down, Bob and Alice go to any other node to which they are both connected.

A super node is a node that has an external IP address and Tox ports are forwarded.

What else has Tox learned?

- Accelerated work DHT network
- Mass chats (Initial implementation, without encryption, without synchronization of meta-information)
- Audio / video transmission (Fully implemented, at the audit stage)
- File transfer
- IPV6 support (all tested, except group chat)

The main thing

Everything described above is implemented in the kernel, not in the shell, in other words, the final clients cannot use many useful functions (for example, transfer audio / video or files) (not all clients are able to)

On the other hand, the main thing is to implement functions in the kernel, it is much easier to write a shell than to standardize the kernel.

In addition, the Tox project is participating in the Google Summer of Code, which means that new developers will soon enter the project.

Oh good

- For Android, the client is actively developing the github.com/Astonex/Antox
- Now for Windows there are as many as 3 clients
- Now for all (including Linux) platforms, there are ready-made assemblies in wiki.tox.im/binaries packages