We offer Tor-like onion routing and privacy protection. We use self-organisation (without servers) in academically-pure P2P style.

We have implemented the main parts of the Tor wire protocol within Tribler. Instead of the TCP protocol that Tor uses, we use the UDP protocol, in order to be able to do NAT traversal. We have created our own network using this Tor variant, our code is not compatible with normal Tor. We use UDP-based end-to-end congestion control. Having hop-by-hop congestion control is one of the key reasons why Tor is slow. Essential part of our work is that everybody who downloads anonymously also becomes a relay. Our work brings the Bittorrent tit-for-tat idea to darknets. You help other become anonymous to get your own privacy.

Weakness: we do not offer the same level of anonymity as Tor, decentralization weakens security.

Disclaimer: Tribler is produced independently from the Tor® anonymity software and carries no guarantee from The Tor Project about quality, suitability or anything else.

The creation process is initiated by sending a CREATE message. There are two distinct cases when a circuit is made. In the first case the originator initiates the creation of the circuit. In the second case the end of the circuit creates a circuit by request of the originator, extending the original circuit. It is important that the recipient of the CREATE cannot distinguish between these two cases, otherwise the identity of the originator can be trivially determined. When the originator wants to create a new circuit it sends a CREATE message to the first hop, containing the circuit id the originator assigned to this circuit. When the first hop accepts the CREATE request it sends a CREATED message back as confirmation.

Message types:

• CREATE Each time a node wants to create a new circuit it sends the CREATE message to the first hop.
• CREATED When a node confirms a CREATE request it sends back a CREATED message.
• EXTEND When a node wants to extend its circuit it sends an EXTEND message along the circuit.
• EXTENDED If the circuit has been extended the EXTENDED message propagates back to the origin.
• DATA Transferring data between nodes is done using the DATA packet. If a packet cannot be routed it will be sent over a direct line, the sending node acts as EXIT node.
• PING Requests a PONG for keep-alive purposes, also used for circuit breakdown detection.
• PONG Reply to incoming PING messages

Show below is the onion encryption and decryption. We use a simple Socks5 interface to talk to the circuits.

The detailed byte-accurate specification of our enhanced Tor-subset is as follows:

Every time a circuit is extended with an additional node, the creator of the circuit and the node with which the circuit is to be extended randomly generate a new keypair. Next, both nodes exchange CREATE/CREATED messages which are used to inform one another about their respective public keys. Once this process has completed, a shared secret is agreed upon through the use of Curve25519 Elliptic Curve Diffie–Hellman.

After having established a shared secret, all subsequent packets will be partially encrypted using AES-GCM-128. The packet header is unencrypted and consists only of the circuit identifier. The packet content is always encrypted. For each message, its contents are encrypted as a separate GCM stream. To prevent IV reuse, IVs are constructed from a counter and a fixed part determined during key agreement. Upstream and downstream traffic use different keys. There are five different ways to decrypt an incoming packet which depend on the circuit identifier and position of the node in the circuit:

• Circuit identifier + sender combination unknown The packet is decrypted with the private key of the recipient. Drop packet if unencrypted packet is unreadable or not a CREATE packet.

• Circuit identifier + sender combination known, last node in circuit The packet is decrypted with AES and the shared secret that the recipient knows it has with the circuit identifier. Possible packet types: Data request or EXTEND.

• Circuit identifier + sender combination known, first node in circuit The packet is decrypted concurrently with AES and the shared secrets that the recipient knows it has with each hop in the circuit, starting from the endpoint to the first node in the circuit. Possible packet types: EXTENDED or RELAY.

• Circuit identifier + sender combination known, direction endpoint The packet is decrypted with AES and the shared secret that the recipient knows it has with the circuit identifier. Possible packet types: RELAY.

• Circuit identifier + sender combination known, direction originator The packet is encrypted with AES and the shared secret that the recipient knows it has with the circuit identifier. Possible packet types: RELAY. The originator of the circuit is the only node in the circuit that initiates packet transmission. The sent packets are always encrypted depending on the type of packet and status of the circuit.

We try to remove bugs, issues and performance problems with our testing framework running on our university supercomputer cluster, several large-scale trials and simple unit tests.

Our first milestone was 5 MByte/sec download speeds with simple unencrypted relays in November 2013.

Anonymous downloading of a Bittorrent swarm was tested during a successful small trial in December 2013.

Stress testing using 8-hops (thus 8 layers of encryption) on 21 March 2014. We surprisingly even got 147 KByte/seconds with such a CPU-heavy test and few code optimizations.

Tribler V6.3 release includes an anonymous test download via roughly 8 onion circuits of 3-hops each. A total of 50MByte is downloaded to test the encryption efficiency, download speed and robustness of our approach.

For the big release of Tribler V7.0 we will offer generic anonymous downloading and streaming of any content. Last February'14 we already got this operational in principle. However, more trials and testing is needed to ensure is will scale to potentially over a million of users.

We use our Jenkin server to conduct automatic testing. The current code is able to obtain 5 MByte/sec throughput when all encryption is disabled. With encryption enabled on modest hardware this is reduced to .5 MByte/sec. A clear point for improvement. A new Beta feature is making the encryption-layer tolerant to packet loss.

We weaken security with decentralization.

We build upon the excellent work by the Tor community. Decentralization unfortunately makes our approach weaker than the original Tor protocol plus network. The Sybil attack is a known weakness in the current anonymous streaming design. We have conducted years of research on Sybil attack defenses. However, it will take a single developer over a whole year to implement these ideas. Volunteers welcome!

1. For now we do not use padding on every message
2. Incentive compatibility. Use our robust reputations to prevent freeriding
3. Sybil attack countermeasures
4. use DTLS for point-to-point link encryption