Internet privacy issues have grown in recent years to be a matter of public debate, and with that, anonymous online communication has turned into one of the hottest topics. In this field, The Onion Router (Tor for short) has come to be the dominant player for those seeking to anonymise their online behaviours. Now, however, it faces upcoming challengers.
The Onion Router (Tor)
The core of Tor is a third-generation onion routing system developed by the U.S. Navy’s research laboratory. It was originally designed to protect the privacy of data communications amongst government agencies. Nowadays, it has found widespread adoption by private enterprises, organizations, institutions, as well as individuals seeking to secure their data transmissions. Despite being widely accepted and adopted, Tor has its weaknesses.
Firstly, Tor is not a decentralized network. Tor is layered network that relies on a series of directory authorities. These directory authorities are centralized servers operated by groups of volunteers that work closely with the Tor Foundation. This highly centralized system is actually vulnerable. The closure of a significant number of directory authorities located in the US, Germany, or the Netherlands is more than enough to destabilize the whole network and decreases the effectiveness of relays and interaction on the network.
Secondly, Tor only supports communications through TCP. Services such as VOIP and RTSP media streaming, which are based on other protocols such as SIP, are therefore not available on Tor. Hence, Tor is limited in terms of the types of services it can support.
Lastly, Tor is not robust enough for threats such as Sybil Attacks. Theoretically, as long as enough relay nodes would be forged and connected to the network, Tor’s users would experience a high probability that all three relay nodes used for data transmission in the network would be forged nodes. In that case, users’ data will be decrypted and acquired by the attackers.
Is I2P the remedy for Tor’s weaknesses?
Data transmission processes in the Invisible Internet Project (I2P) is done through one-way tunnels, meaning that two unique routes will be used for data transmitted from the client to the server and from the server to the client. To solve the centralisation problem and prevent the server addresses from being attacked, I2P divides the nodes in its network to Floodfill nodes and Non-Floodfill nodes. The initial default identity of any node is Non-Floodfill and only qualified nodes will be “upgraded” to Floodfill nodes. The I2P system will connect all the Floodfill nodes via a Kademlia algorithm which then forms the I2P database, resembling the directory authorities in the Tor network.
Floodfill nodes will store two types of data, namely RouterInfo and LeaseSet. RouterInfo includes nodes’ ID, public key, signature, universal protocol and port info, whereas LeaseSet contains information such as Hash value, entry point of transmission tunnel etc.
The topology of I2P is shown below. Every node is distributed across the logic circle according to a 256-router-key. Their logical positions are updated daily, leading to different node distribution patterns. The nodes will also upload data to different Floodfill nodes. This mechanism is designed to defend the network against Sybil Attacks.
As part of transmitting data, clients and servers will have independent inbound tunnels and outbound tunnels. A complete data transmission process will involve four tunnels in total. In this process, encrypted data will first be sent to outbound tunnel gateways and encrypted again before being transmitted to the server through the inbound tunnel. The server will then decrypt the data and repeat the same procedure to communicate with the client. Each node involved only knows the encrypted data it received and the data it then transmitted, thereby hiding the identities of the communicating parties. Anonymity is therefore achieved.
I2P solved the potential problem caused by centralized directory authorities and made it expensive to eavesdrop the network. However, the multiple encryption and relays in the data transmission process also leads to longer response time. The threat from Sybil Attack persists as attackers can still jeopardize the network by forging intermediate nodes. More importantly, both Tor and I2P rely on volunteers to maintain the nodes and thus the services of the networks can be inconsistent unless proper incentives are given to the volunteers.
Encrypted Communication on SmartX
The SmartX Low Latency Anonymous Protocol (SLLAP) combines the advantages of Tor and I2P. It stores the public key of server nodes and other online clients as well as entry points in the DHT network. In this way, server nodes and clients will have multiple entry addresses yet none of the addresses will be the real IP.
SLLAP maintains the DHT nodes by using a Kademlia Algorithm and avoids the centralization problem by making the DHT network dynamic, thereby preventing attackers from launching focused attacks. At the same time, SmartX also conducts periodical nodes tests to ensure the security and robustness of the network. The following tests will be conducted:
- Band width test: Every new node on SmartX must pass the bandwidth test. Once passed, it means that this node has a bandwidth that is above the minimum threshold required.
- Message storage test: Messages will be stored in SmartX server nodes for a short while. Therefore, the mechanism of message caching is extremely important for SmartX as it determines if offline users can receive the message correctly. The test serves the purpose of detect nodes that have only low performance configurations and do not provide message caching.
- Block storage test: SmartX server nodes need to store complete blocks to complete tasks such as transaction verification and lock-ins. Honest nodes will store the copies of the blocks permanently.