Darkcoin Code Review Results

Summary: I identified no significant security vulnerabilities in the closed source Darkcoin code. There are three privacy implementation issues that have been acknowledged by the Darkcoin development team and are being fixed; full disclosure of those issues will take place no later than 2014/10/18.

As part of my crowd-funded review of Darkcoin, I have spent the last few weeks manually reviewing the source code of the currency.

Though I am by no means the authoritative expert on reviewing C++ code in general  or crypto-currency code in particular  for security vulnerabilities, I have been reviewing C/C++ code for security vulnerabilities on a common basis and professionally for 4+ years.

When requesting crowd-funding, I sketched the following scope of code review:

  • Examining the code for typical C/C++ bugs: buffer overflows, format string vulns, heap-based vulns, data value errors (e.g. integer overflows, integer comparison bugs). I don’t expect to find much in this department, since Darkcoin was forked from a carefully written codebase that has already been heavily audited (Bitcoin/Litecoin). Depending on what’s going on in the code, I may also look for less common issues such as environment variable abuse, Time-of-check-time-of-use vulns, multithreaded/re-entrant code issues, error handling, character encoding, and so on. I won’t be fuzzing or otherwise dynamically interacting with binaries. I’ll be sticking to manual review of the code, with the exception of a few static analysis scripts that I’ve written myself (but haven’t gotten around to open sourcing yet). I’ll pay particularly close attention to areas of the code that handle outside sources of data, since those are usually the focus of attackers.
  • Double-checking the design of DarkSend+ to see if any issues surface while examining the implementation that didn’t come up while discussing the design.
  • Ensuring that the implementation complies with the design.

The results of my design review can be found in my previous blog post on the topic, with an updated version of the paper (v2) found here.

I reviewed version of Darkcoin, the binary of which should be released in the coming days (likely with some small modifications) as Release Candidate 5. I compiled the code and verified that it was the expected version, with a MD5 hash of the darkcoin-qt 32-bit Linux binary of 0x348d884373f698714bf3f047d3889443.

Since the public has had a lot of opportunity to review the open source code, I focused mainly on code that has not been previously released to the public, comparing it to the open source code from the public repository bearing version I reviewed every single line of the thousands of line of code that differed from that public repository manually for potential security vulnerabilities. I looked for both intentionally and unintentionally introduced flaws. I also used various tools and methods to search the total Darkcoin code base for certain classes of vulnerabilities.

Over the course of the review, I identified no significant security vulnerabilities in the closed-source version of the code. In general, the closed source code is consistent in style and convention to the open source version of the code, and does not introduce novel methods of security-impacting functionality, such as the handling of strings or memory management. Though it is difficult to guarantee the absence of cleverly hidden backdoors, I found no suggestions of any such implantation.

The few minor potential security-impacting issues that I have identified are unlikely to be remotely exploitable, and I passed them on privately to Evan for his consideration. I am not aware of any bugs that could be used to disrupt the network or steal funds.

I have identified a few privacy-related issues in the code. For the time being, I recommend that users pause use of Darksend+ for privacy purposes, or bolster them with other blockchain privacy tactics as part of a privacy-in-depth strategy, until the issues can be fixed; these issues were reported to the Darkcoin dev team on 2014/09/18, and acknowledged by email by the dev team on the same day. All will be fully disclosed by 2014/10/18 as part of “responsible disclosure” practices. I expect that they will be addressed sooner than 2014/10/18; if corrected Release Candidate binaries are made available before then, I will disclose the issues at that point. For the time being, I’m reserving the following IDs for the issues so that their status can be tracked:

  • ATLAS-20140918-01
  • ATLAS-20140918-02
  • ALTAS-20140918-03

For those Darkcoin enthusiasts who have the time and skills to do so, I would encourage them to carefully review the code contained in the open source version of util.cpp, in particular code that handles format strings. This file differs significantly from the reference Bitcoin version, and handles sensitive data. When I asked Evan about the file, he wrote back to me:

One of the Bitcoin developers, ‘rebroad’ wrote a bunch of improvements to the way debugging is done for the Darkcoin project. It hasn’t been accepted into Bitcoin yet, but I thought it was really neat so I included it.


As I stated before, it is likely that this file has been thoroughly reviewed by others before, including its author.

Lastly, I want to mention one piece of trivia that came up during the review: The code currently limits users to at most 8 rounds of Darksend+, and ignores higher specified values. The relevant line of code is:

if(nDarksendRounds > 8) nDarksendRounds = 8;

Evan wrote to me about this decision:

8 rounds is where the probably of following a transaction falls to almost zero. For example if an attacker controlled 100 of 900 Masternodes, they would be able to see 5.94e-06 of the transactions with 8 rounds (the math is a little different, but as a rough calculation you can do (n/t)r, where n is the attackers nodes, t is the total nodes and r is the rounds of Darksend).

Thanks once again to all those funded my review effort. Evan was extremely helpful throughout the process, promptly and quickly responding to my queries. I look forward to future collaborations with the Darkcoin community, and with other privacy-centric crypto-currency projects, as well.

[Paper] An Analysis of Darkcoin’s Blockchain Privacy via Darksend+

There are at least two reasons why Darkcoin is so interesting to me:

  1. It is the most popular privacy-centric crypto-currency to date, with the largest market capitalization.
  2. The privacy technology is based primarily on the CoinJoin protocol first proposed for implementation in Bitcoin. Much of the technology included in Darkcoin’s privacy approach, Darksend+ is adaptable to Bitcoin clients. It is the best funded and most actively developed CoinJoin implementation in the world, currently.

This is the first deliverable from my crowd-funded analysis of Darkcoin’s privacy technology, Darksend+. This paper discusses the design of Darksend+, identifies strengths and weaknesses of the technology, and proposes potential mitigations and improvements to any weaknesses identified.

Since much of the design of Darksend+ can inform other CoinJoin implementations, I hope that this paper will not only shed light on the current state of Darksend+, but provide insight into how to analyze future CoinJoin implementations in general.

I would like to thank Evan Duffield and Justus Ranvier for generously giving their time to review the paper and providing feedback.

Currently I consider the document to be an early version, and request public comment. As mistakes are identified and clarifications are required, I will continue to update the document.

[Download the paper]