Privacy Snake Oil Salesmen (Part One): Tornado.Cash


13 min read
Privacy Snake Oil Salesmen (Part One): Tornado.Cash

Taking a step back from all of the 'DeFi' stuff, markets, etc., that has been captivating everyone's attention - I figured I would take a double back to take a look at a project called, 'Tornado.Cash'.

They caught my eye a few weeks ago as I was reading a report about the 'hack' of Balancer Protocol's pool (refresh yourself here).

Specifically, 'Tornado.Cash' was referenced here:

Upon reading the excerpt above, I thought to myself:

"What the hell is Tornado.Cash?"

A Really, Really Bad Attempt at Privacy (and Security) on Ethereum's Blockchain

For some reason, the blockchain space has been infatuated with the idea of manifesting privacy-focused solutions on public blockchains.

Slowing Down on That 'Public Blockchains' Bit

Most folks reading this are probably more than educated on the fundamentals of blockchain, but I feel there's one concept that doesn't get iterated enough.

And that's the idea (truth, rather) that blockchains were made public by design.

Well Duh

Sure, this seems obvious to most, but I genuinely question whether the larger blockchain space is adequately accounting for this fact.

Why This is Important

Certain characteristics of Bitcoin / Proof of Work blockchains manifested as a result of the evolving community and ecosystem itself - like the production of "tokens" that are manifested from the chain itself, but are imbued with inherently restricted / inferior qualities than its "native token" counterpart (i.e., tokens vs. actual $BTC / $ETH / $LTC).

To put this in layman's  terms, what I'm saying here is that no one could've picked up Satoshi's whitepaper back in 2008/2009 and interpreted it to as a precursor establishing the constitution for a project like Ethereum.

However, this is not the case with blockchain's public ledger.

The public ledger essentially fuels the idea of blockchain itself in the following ways:

It allows the mining ecosystem to exist in a way where blocks submitted by miners can be checked for accuracy by all participants on the system (using the public blockchain, of course).

The protocol's design choice to task all nodes on the network with the responsibility of auditing the blocks submitted by miners (and they do), along with software imbued in each which compels said nodes to reject blocks with invalid transactions means that miners are heavily incentivized to remain truthful (lest they have their fraudulent block rejected - wasting their efforts).

Following from #2, there would be no incentivization structure in place between nodes and miners if Proof of Work didn't exist because it is designed to apply an ever-increasing cost as more participants join the ecosystem and begin "mining".

This cost is applied and enforced by the protocol rule that reqiures miners to include the hash of the former block along with the latest one that they attempt to submit to the protocol. This, of course, is what provides the "chain structure", which would be impossible to establish and + or verify without the purposefully public, transparent nature of blockchain.

With all that being said, let's go over and take a look at 'Tornado.Cash' (finally).

Tornado.Cash (Brief Overview)

As you probably guessed from the excerpt shown above (amid the backdrop of the article's context - covering a 'DeFi' hack), 'Tornado.Cash' must be some sort of secretive  / encrypted / private protocol of some sort if it was used as the vehicle of choice for the alleged balancer pool hackers.

And, of course, since these guys are hackers - one would have to imagine that this hacker(s) would be excessively picky about whatever privacy scheme they choose given the highly (potentially) illegal nature of their actions [we'll get into the reason why I said 'potentially' in another piece soon, I promise].

Assuming my assumptions are true, we may have stumbled upon a really awesome, innovative new privacy solution that protects its users like no  other solution has before.

Starting at the Root

There's not a ton of concrete information about this project's origins, but based on what is out there - it appears these guys (whoever is behind this entity) started making their "big splash" in 2019.

This article here on 'defirate.com' explain the project succinctly (see here): https://defirate.com/tornado-cash/

A 'Mixer'?

Yup! Appears that its a mixer. Which is hardly a novelty in the blockchain space, let alone in the field of "privacy", but this is how Tornado.Cash presented itself to the world in 2019.

"What is a mixer?"

Mixers are 3rd-party tools / entities that provide the service of obfuscating transactions by "mixing coins".

How This Works (Brief)

If you've ever used a blockchain explorer before, then you've more than likely seen how painfully simple it can be to track down the flow of transactions from one entity to another. But that's not a coincidence, of course, As we dissected above - this is a purposeful (and critically necessary) facet of the blockchain design.

Without casting any judgment or making assumptions here - the reality of this service is that it tends to be marketed toward those that are engaged in activities that their respective jurisdictions would view very unfavorably should they ever 'catch wind' of what's going on (penalties range from steep fines, to incarceration and perhaps even death if we consider the entire 'universe' of users that have solicited the services of a 'coin mixer').

In order to break the linear (and easy-to-follow) transaction chain of Johnny to Bob to Sarah to Jake, mixers aggregate transactions from a large pool of senders, then they break down those transactions into smaller "pieces" and send them all through a interconnected web of wallet addresses until they reach their intended destination(s) [a smart mixer would mandate customers provide more than one destination address]

The goal (and purpose) of orchestrating hundreds (if not thousands) of transactions at a time is to create enough obfuscation and complexity in the transaction routes to deter any external 'observers' from exerting the effort necessary to actually track down each individual transaction back to its origin point (here, I'm using the word observers' in a literal sense; i.e., watching transaction movemoents on a block explorer).

Obfuscation is Not Privacy

You're going to see me saying this a lot throughout the rest of 2020 and likely into 2021 and beyond (sadly).

But this is a slogan that bears repeating whenever discussing the idea of "privacy" itself.

And if this sounds like a game of semantics to anyone reading this, then I'll just quietly assume that they aren't true students of Timothy May (the guy that wrote the original 'Cryptoanarchy Manifesto', whom many consider to be the 'godfather' of the "cryptoanarchy" movement itself).

Semantics Meant Everything to Timothy May

While Timothy May's technical brilliance is well-documented (and a major catalyst for his prominence + success), this facet of his person was not what fueled the cryptoanarchist movement.

Timothy May's Manifesto Was Philosophy

Plain and simple.

And if you've taken a Philosophy class (of any sort) in college or elsewhere, then you'll agree that semantics are the backbone of philosophy (and if you still don't agree / know what I'm talking about, then I'll just asswume you were too hungover to go to class that semester).

Taking a Quick Look at the Manifesto

This document is published in countless different places online, but I decided to re-publish it here (for everyone's convenience so you don't have to go hunting for it): https://notes.librehash.com/s/rkseYZSbw

Below are the two most interesting excerpts from this brief speech (there's a much longer, yet less well-covered document that Timothy May posted around the time of this publication that explains his ideas, the underpinning for his philosophy, motivations and more):

Main Point Here

The purpose of this write-up is to challenge the solutions that have been proposed in the blockchain space over the past 2-3 years related to 'privacy'.

This is also a lead-in to a greater critique of the broader blockchain space - specifically as it pertains to the activities and roles of so-called "developers" and "developing teams".

Back to 'Tornado.Cash': Evaluating the Audit

Towards the end of December 2019, Tornado.Cash put up a tweet from its account (Twitter), declaring that it had "passed" a 'security audit'.

In that tweet (shown below and linked), Tornado provided links to three separately published sources for their audits. We'll take a brief look at those in a second.

Here's the original tweet:

And Below are the Three Separately Linked Audit Reports From Said Tweet:

  1. Cyrptographic Review: https://tornado.cash/Tornado_cryptographic_review.pdf
  2. Smart Contract Audit: https://tornado.cash/Tornado_solidity_audit.pdf
  3. Zk-SNARK Circuits Audit: https://tornado.cash/Tornado_circuit_audit.pdf

Why We Need to Even Look at the Audit

Contract to popular belief (at least in the blockchain world), simply receiving an audit is not a positive sign (in itself).

And that's because anyone with enough money can manage to land themselves an audit from someone.

Additionally - there have been many times where an audit has actually been to the detriment of the subject of the audit.

How This is Possible?

If an audit uncovers egregious issues with the project / organization in question, then this could create widespread mistrust and doubt by the general public in the developers' actual competency.

Sometimes, audits can be indications of other nefarious / questionable activity.

Without anticipating it, it appears that we may have stumbled on to the latter here.

Major Conflict of Interest in the Very First Audit of the List

Specifically, this section's title is referring to the audit report titled, 'Tornado Privacy Solution Cryptographic Review Version 1.1' [source: https://tornado.cash/Tornado_cryptographic_review.pdf]

According to the pdf, this portion of the audit report trio was was conducted by 'Dmitry Khovratovich' and 'Mikhail Vladimirov' ; two individuals whom apparently produce research for "ABDK Consulting".

So far, so good - all appears normal.

Well...at least until we get to 'section 3' of the audit - titled, 'Implementation'.

Uncovering the Strange Conflict of Interest That Undermines the Purpose of the Entire Audit

It goes without saying that an audit is only seen as an effective step toward transparency and the spread of information / due diligence for interested and affected participants in a given market due to the supposed neutrality of the auditing party.

To be clear - there's an implicit (and often times, explicitly declared) expectation of separation between whatever is being audited and the auditors themselves.

Otherwise, the audit would be completely pointless.

Despite These Clear, Embedded Standards - Tornado.Cash and "ABDK" Whiff Terribly

This is actually admitted in the audit directly (see below):

Wait, what? Did they just say that one of the smart contract codes deployed by 'Tornado.Cash' that they were tasked to audit was originally created by them??

"The Solidity implementation of Merkle tree, depsoit and withdraw logic is by the authors."

Fortunately, there's a fotonote next to this disclaimer as well.

So let's check it out.

Taking a Trip to GitHub

Here's the link to footnote number three, which was cited directly in the text itself as the repo in question, that the authors own: https://github.com/tornadocash/tornado-core/tree/master/contracts

Starting Our Brief Visit

"But I Have No Clue How GitHub Works!"

Don't worry, you don't have to, to verify this for yourself (we're not peering into any code here).

Revisiting the Screenshot Briefly

Below is a modified version of the screen captured repo that we posted in the previous section.

This time, we took care to identify one of the project's authors.

That picture above:

A) Identifies one of the contributors to the code (that thumbnail of a person, boxed on the left-hand side).

B) When they authored their last change to the code (boxed on the right) ; as we can see, that was on April 13th, 2020 - not too long ago from the time of writing (August 2020).

Noting the Contracts That 'Pertsev' Was Working On

In the pictures below, we isolate each one of the contracts that "Pertsev" was working on below:

Here are the Commits (all the individual changes made to the codebase itself):

Noticing what we're seeing?

Don't worry, your instinct is correct - this person is the only individual that's contributed to the codebase over the past few months.

Keep in mind that we landed on this repo specifically because the audit was allegedly "commissioned" by 'Tornado.Cash' in the spirit of transparency. Right?

Who the Hell is This "Petersev" Guy?

Okay, enough with the suspense.

Its time for us to find out who "Petersev" really is.

Here's His Main 'Profile Page' on GitHub

(source: https://github.com/pertsev)

That doesn't tell us too much though.

But one thing that does is the, 'Peppersec' organization on GitHub.

You can find the link to their organizational  page here: https://github.com/peppersec

What Do They Have to Do With Anything?

Great question.

If we re-visit those links referenced in the 'cryptography' audit that Tornado.Cash received, we can see "Peppersec" is located in both links:

What Does That Mean?

Being familiar with GitHub tells us that 'peppersec' is the individual/entity that that owns (and ultimately, published) those smart question.

Keep in mind, these are the smart contracts by Tornado.Cash that they allegedly 'commissioned' auditors to review.

It Appears Petersev is a Team Member!

gasp

Okay, but seriously - this wasn't hidden under anything large.

Going back to the repo link, one will notice that 'Peppersec' is not the "owner" of the repo (shown below):

The picture (and its annotations) above tell us that the name of the organization changed from 'Peppersec' to "Tornadocash".

Interesting.

Fortunately, they aren't gone for good!

Petersev and Peppersec

Here's a link to one of their repos (from a little over a year ago): https://github.com/peppersec/thunder_bridge

Well, what do you know? There's Peter all over again.

What is he doing here?
And what is 'Peppersec'?

Quick Look at 'Peppersec'

I'm not going to spend too much time here, because the scheme should be tacitly obvious at this point.

But there are a few things that are worth noting here about "Peppersec".

(In particular, repos such as this one)[https://github.com/peppersec/multisender_statistics]:

Where it appears here that they were extracting statistics / usage information from the users of the 'multisender.app' and using said information to craft a research report (for who?) that attempts to deduce the optimal gas fee based on said numbers.

That Feels Illegal and it Probably Is

But hey, now you know!

Curiously, it appears that this team has quite a few repos that link to Chainlink as well.

Are they also part of Chainlink's team?

The question posed above about these individuals being part of Chainlink's team was a joke to throw in some levity here.

But to be more serious - it appears that these individuals are more than likely the creators / maintainers of the 'multisender.app' platform.

And if they aren't, then they must be really, really really HUGE fans.

Confirming 'Alexey Pertsev' Involvement

This report technically hadn't proven that the same "Pertsev" individual we spotted developing for Tornado Chain was the same as the entity that was allegedly conducting the "audit" of Tornado's code - but fortunately, one need look no further than 'CypherHunter':

(source: https://www.cypherhunter.com/en/p/peppersec/ )

Taking a Look at the Actual Audit Report of Tornado.Cash

The cryptographic review yields considerable cause for concern.

Essentially, the excerpts above make it clear that:

  1. Tornado.Cash's entire cryptographic scheme was out of wack (in every way that a cryptographic scheme could be).
  2. There were several flaws in implementation that would have made guessing private keys a trvial task for would-be attackers (suicide in the context of cryptocurrencies where the compromise of one's private keys = game over).

No Proof the Team Made Any Palpable Changes to the Smart Contracts

Typically, in an auditing report, the auditors will cover their interaction with the team and provide information about whether the team followed through on the advice / corners of the auditors, subsequently amending the points of concern that were identified.

However, in this instance - that was not done.

Rather instead, there were some recommendations that were made toward the end of the paper regarding "optimizations", but not too much beyond this.

Potentially Incorrect Application of 'Pedersen Commitments'

To Tornado.Cash's credit, they make this fact clear on the project's GitHub page (see below):

Appears That 'Tornado.Cash' is Planning on Provisioning Their Own Token at Some Point in the Future

Check out this Medium post by 'Tornado.Fund' titled, "Decentralizing TornadoCash: The Launch of Tornado Fund and the Path Towards TornadoDAO"

Link is here = https://medium.com/@Tornado_Fund/decentralizing-tornadocash-the-launch-of-tornado-fund-and-the-path-towards-tornadodao-a6d4ffc6c800

Takeaway: Appears That a Token / Coin is in the Works For Users

This is probably obvious to most reading, but just in case it isn't...

What makes this interesting is that there are a wealth of instructions on the 'Tornado.Cash' GitHub that supposedly map out how users can deploy these tokens in live time.

Compliance Tools?

The announcement of 'compliance tools' for a platform that's meant to be entirely private via the integration of zero-knowledge cryptographic proofs seems (rightfully so) contradictory.

See below (from the same Medium announcement we were looking at):

GO TOP