Explaining the Tor Layer in Tangram: Part 1

Published in

Tangram

5 min readMar 29, 2019

A major part of Tangram’s goal is to deliver a private network and protocol with “a highly-sophisticated and scalable digital payment system” that will allow “businesses, investors, and individuals to make secure and privacy enhancing transactions with unprecedented speed”. Therefore, building a privacy layer on top of the base protocol was crucial from the start. While it is important to note that no network is 100% anonymous, the goal of Tangram is to strive to make network attacks increasingly difficult. One of the ways Tangram achieves this is through the use of the free and open-source Tor network (active since 2002) as one of the tools to deliver a private communication layer.

Tor uses an array of computers or nodes to obfuscate network traffic by routing it through encrypted connections. This way, it offers digital anonymity to its users, while discouraging surveillance. By integrating Tor, Tangram joins a list of projects, such as Brave, which borrow from a service widely renowned for its efficiency in protecting privacy.

However, layering Tangram with Tor wasn’t easy or straightforward. It took significant work and development time. An initial plan to use Tor v2 hidden services failed because there was no convincing way to verify that a message indeed came from a specific node. The reason for this is that .onion addresses in this Tor version cannot be reliably decoded into a public key, a crucial step in identifying the node and allowing the receiver to verify a message signature using the sender’s public key.

Tor v3 hidden services solve this problem. In this newer version, a unique public/private key pair is automatically generated and attributed to each node. This pairing can serve a lot of useful purposes, including identifying nodes, allowing unique signing of messages or preventing node impersonation.

To facilitate this integration, Tangram forked a comparable implementation of Tor’s ed25519 signature scheme. This offers a range of possibilities in the usage of Tangram as a currency. Not only does it allow nodes existent on Tangram network to stay anonymous by hiding their IP addresses, it also enables them to change their identity anytime they want to.

The following is a simplified code example which illustrates signing a message using an ed25519 private key. We take the v3 onion address, convert it into a public key and then verify the message signature with the public key.

In this example:

represents a v3 onion address. These are much longer and as a result are easy to differentiate from v2 addresses (e.g. facebookcorewwwi.onion).

Next we define the associated ed25519 private key we will be using to sign the message:

In our example we have hard-coded the private key. In practice we load this from the hs_ed25519_secret_key file stored in the onion/hidden_service directory.

Next we decode our .onion address to an ed25519 public key using the following method:

This method decodes the address using the spec defined here: https://github.com/torproject/torspec/blob/master/rend-spec-v3.txt#L2029-L2051

Once we’ve loaded our ed25519 public/private key pair, we can begin constructing a basic message. In this case our message is a simple string:

We’re now ready to sign the message:

The resulting signature is 64 bytes long.

We can then verify that our signature is correct for the message specified above by passing in the signature, the original message, and the public key:

Of course this is a simplified example. In actuality our messages are a JSON payload and we sign the hash of the message instead of the entire message payload itself. We also include additional protections (eg. a timestamp to prevent replay attacks).

As a side-note, do not attempt to utilize the above public/private key pair as they are already blacklisted within the Tangram network.

Pluggable Transports

Another feature offered by Tor which we have integrated is Pluggable Transports. Sometimes the Tor network is censored by your ISP and some entities use a data processing method called ‘Deep Packet Inspection’. On the one hand Pluggable Transports help you bypass censorship against Tor; on the other, it also protects against passive Deep Packet Inspection and prevents others from identifying obsf4 protocol. This keeps third parties from assessing or knowing what protocol is in use based on the message contents.

When you start your wallet it is automatically configured to utilise Tor’s Pluggable Transport. Presently, Tangram utilises obsf4 transport which is recommended by Tor as “currently the most effective transport to bypass censorship”.

You can read more about Pluggable Transports and obsf4 here:

Tor Project: Pluggable Transports

The Tor Project's free software protects your privacy online. Site blocked? Email [mailto:gettor@torproject.org] for…

2019.www.torproject.org

Yawning/obfs4

The obfourscator (Courtesy mirror). Contribute to Yawning/obfs4 development by creating an account on GitHub.

github.com

Further evaluation of obsf4 can be found here:

https://trac.torproject.org/projects/tor/wiki/doc/PluggableTransports/Obfs4Evaluation

You may also find reference to the Tor (onion) implementation in Tangram’s wallet here:

tangramproject/Cypher

Tangram CLI Wallet. Contribute to tangramproject/Cypher development by creating an account on GitHub.

github.com

Node Discovery & Communication

Tangram nodes use Tor to deliver the membership list within the network using the SWIM protocol, i.e. it facilitates nodes leaving and joining the network. Currently we utilize message signing in our SWIM protocol implementation. However, we plan to expand it to other aspects of our inter-node communication.

Unlike Nodes, wallets do not have an identity and do not run a hidden service. They merely communicate to Tangram Nodes over Tor. This means that messages coming from a wallet do not generate signatures. When a message from a wallet is received at a particular node it is validated and if valid is propagated to other nodes in the network. However, it is noteworthy to mention that the wallet was the first step in the design and development of a structure which offers network-level anonymity for peer to peer transactions on our base protocol, including but not limited to the “hiding” of transactions on the blockchain.

We will provide more elaboration in future related articles.

Future plans

While our Tor implementation offers excellent privacy and anonymity, it is always in our best interest to look forward and improve. Because of its network nature of relay and exit nodes, Tor is a little more centralized. We have been investigating the possibility of utilizing Repliable Datagrams in I2P in place of Tor. Utilizing I2P would open up the possibility of great performance improvements, while promoting fuller decentralization. Fortunately, our codebase has been effectively structured in modules so that when needed such an upgrade can be easily applied.

For a comparison between I2P to Tor, read the comparison page here: https://geti2p.net/en/comparison/tor

In the past, support for privacy-preserving and enhancing technology was low due to inefficiencies and cost. Today, with the advent of cryptocurrencies and blockchain, the conversation on privacy for real-world use cases has been reignited. As a result, there are now improved and new concepts for mix-nets, cryptocurrencies and anonymising technology that we can employ as means to reach the goals of Tangram and other privacy-preserving applications in the future.