Uncategorized

Joining the Blockchain.info Team, OBPP

2014 was a big year for me. My love of crypto-currencies, and their security and privacy possibilities in particular, blossomed. A few of the highlights included:

As 2014 started to come to a close, however, I realized a couple important things. First, a lot of the projects that I worked on during the past year were highly individual. Although Bitcoin and crypto-currencies are relatively young, there are already some incumbent  actors who hold a pretty massive marketshare over the software ecosystem and user base. In such a landscape, there is a limit to how much one person alone can accomplish. The second realization was that I missed working collaboratively in teams. I like to peek into the activities of my economic collaborators who build software, manage personnel schedules, woo investors, and make the work that I enjoy so much possible.

With these thoughts in mind, I accepted in late December a new position as Security Engineer with Blockchain. It’s a great fit for me, with my background in web application security and passion for Bitcoin. I chose Blockchain not only because they have such a huge marketshare, but also because I believe their goals and personal values are in line with mine. Blockchain aims to put control over funds in the hands of users — Bitcoin newbies, in particular. They are working toward a decentralized future of finance. And when joining a Bitcoin company, it is extremely important to consider the level of integrity that the executives and employees have. Time and time again, we’ve seen companies go under or disappear with apparently stolen money, abusing the recency of the space. Already I knew two friends who worked for the company who I respect highly; and while getting to know the other people at Blockchain, I was impressed with their emphasis on seeking out workers who can be trusted. Not every Bitcoin company has integrity, but I think Blockchain has it in spades.

I am incredibly honored to accept this position. Even though the space is growing ever more vast, there are relatively few high-impact positions when it comes to security, and lots of interested and skilled applicants. Blockchain is a fantastic company. They were my first wallet, and have been tremendous leaders in the industry. I am fascinated by the many different forms that Bitcoin software may take, but it is safe to say that Blockchain’s millions of customers will persist for a long time to come, and will have some serious security and privacy needs to be met.

I am also very excited to accept this position. Blockchain has a number of different products, and many of them live on the incredibly hostile biome of the web. Just when I thought the web industry might be turning a corner in the security war with coordinated efforts such as Content Security Policy and more consistent developer security training, we went and put money on computers. Increasingly, the function of our personal devices will shift in the attention of our prey from feeble spam bots to tiny, personal banks. The stakes have been raised, and it’s going to be one heck of a challenge responding to this new generation of financial threats.

Given the importance of this position, I will be dropping a lot of my former side projects to focus on Blockchain’s customers full-time. This means an indefinite pause on things like Dark News. One side project I will be continuing to work on is the Open Bitcoin Privacy Project. Bitcoin security is starting to get some much-needed love, but I think Bitcoin privacy still needs a shot of adrenaline to get up to par with the legacy systems that Bitcoin will replace. That’s exactly what OBPP will be trying to provide.

Uncategorized

Seeking Bitmessage Code Reviewer

Bitmessage is a decentralized, peer-to-peer messaging network. It’s been a subject of significant interest for crypto-currency developers because its has privacy and networking properties built in that are absent from the blockchain and Bitcoin-like peer-to-peer networks.

Today, Bitmessage is often used as a more private version of email, but if only a handful of weaknesses in the project were resolved, we would probably see it integrated into a number of crypto-currency-related projects. Chief among these weaknesses:

  1. The Bitmessage network, as it is currently designed, would have difficulty scaling to many users. The messages sent around the Bitmessage network are more or less broadcast to all other participants in the network — albeit only readable by the intended recipient — creating a cacophony of unnecessary traffic. One solution is to implement streams, sending messages to a smaller number of recipients while preserving properties that come with broadcasting messages to everyone. Making streams a reality requires the participation of one or more crafty Python developers (or developers of a new Bitmessage implementation).
  2. Bitmessage’s current Python code base has not been thoroughly reviewed from a security standpoint. This weakens the trust of users and software developers who might want to integrate Bitmessage into their own projects.

Some people from the CryptOpinion website are trying to organize a crowd-funded secure code review of Bitmessage. I originally volunteered for the effort, but have another engagement that precludes me from doing so. Do you know someone with secure code reviewing skills who might be interested? Please send them to the CryptOpinion folks.

A Couple Notes for Reviewers

There are not many great tools for static analysis of Python code from a security perspective, so a line-by-line analysis is probably required on some level. Here is the “cloc” output for PyBitmessage’s src:

http://cloc.sourceforge.net v 1.53  T=0.5 s (112.0 files/s, 37088.0 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
Python                          56           1595           1773          15176
-------------------------------------------------------------------------------
SUM:                            56           1595           1773          15176
-------------------------------------------------------------------------------

A free Coverity scan might be a useful resource for any Bitmessage code reviewer.

The Bandit Python code security scanner did not return any results:

$ find PyBitmessage-master/src/ -name '*.py' | xargs bandit -n 1
56 [0.. 50.. ]
Run started:
2015-01-10 21:23:18.598899
Files in scope (56):
PyBitmessage-master/src/pyelliptic/ecc.py (score: 0)
PyBitmessage-master/src/pyelliptic/openssl.py (score: 0)
PyBitmessage-master/src/pyelliptic/__init__.py (score: 0)
PyBitmessage-master/src/pyelliptic/cipher.py (score: 0)
[...snip...]
PyBitmessage-master/src/helper_bitcoin.py (score: 0)
PyBitmessage-master/src/qidenticon.py (score: 0)
PyBitmessage-master/src/shared.py (score: 0)
Files skipped (0):
Test results:
No issues identified.

The result of running RATS:

$ rats PyBitmessage-master/src/
Entries in perl database: 33
Entries in ruby database: 46
Entries in python database: 62
Entries in c database: 334
Entries in php database: 55
Analyzing PyBitmessage-master/src//pyelliptic/ecc.py
PyBitmessage-master/src//pyelliptic/ecc.py:78: warning: bad token `@'
PyBitmessage-master/src//pyelliptic/ecc.py:113: warning: bad token `@'
PyBitmessage-master/src//pyelliptic/ecc.py:128: warning: bad token `@'
PyBitmessage-master/src//pyelliptic/ecc.py:419: warning: bad token `@'
PyBitmessage-master/src//pyelliptic/ecc.py:428: warning: bad token `@'
Analyzing PyBitmessage-master/src//pyelliptic/openssl.py
Analyzing PyBitmessage-master/src//pyelliptic/__init__.py
Analyzing PyBitmessage-master/src//pyelliptic/cipher.py
PyBitmessage-master/src//pyelliptic/cipher.py:38: warning: bad token `@'
PyBitmessage-master/src//pyelliptic/cipher.py:45: warning: bad token `@'
PyBitmessage-master/src//pyelliptic/cipher.py:50: warning: bad token `@'
Analyzing PyBitmessage-master/src//pyelliptic/hash.py
Analyzing PyBitmessage-master/src//pyelliptic/arithmetic.py
Analyzing PyBitmessage-master/src//api_client.py
Analyzing PyBitmessage-master/src//helper_sent.py
Analyzing PyBitmessage-master/src//class_sqlThread.py
Analyzing PyBitmessage-master/src//class_objectProcessor.py
Analyzing PyBitmessage-master/src//class_singleCleaner.py
Analyzing PyBitmessage-master/src//socks/__init__.py
Analyzing PyBitmessage-master/src//helper_bootstrap.py
Analyzing PyBitmessage-master/src//helper_inbox.py
Analyzing PyBitmessage-master/src//class_receiveDataThread.py
Analyzing PyBitmessage-master/src//highlevelcrypto.py
Analyzing PyBitmessage-master/src//helper_generic.py
Analyzing PyBitmessage-master/src//tr.py
Analyzing PyBitmessage-master/src//class_singleListener.py
Analyzing PyBitmessage-master/src//bitmessagecurses/__init__.py
Analyzing PyBitmessage-master/src//bitmessageqt/iconglossary.py
Analyzing PyBitmessage-master/src//bitmessageqt/specialaddressbehavior.py
Analyzing PyBitmessage-master/src//bitmessageqt/addaddressdialog.py
Analyzing PyBitmessage-master/src//bitmessageqt/help.py
Analyzing PyBitmessage-master/src//bitmessageqt/connect.py
Analyzing PyBitmessage-master/src//bitmessageqt/about.py
Analyzing PyBitmessage-master/src//bitmessageqt/regenerateaddresses.py
Analyzing PyBitmessage-master/src//bitmessageqt/bitmessage_icons_rc.py
Analyzing PyBitmessage-master/src//bitmessageqt/__init__.py
Analyzing PyBitmessage-master/src//bitmessageqt/bitmessageui.py
Analyzing PyBitmessage-master/src//bitmessageqt/settings.py
Analyzing PyBitmessage-master/src//bitmessageqt/newaddressdialog.py
Analyzing PyBitmessage-master/src//bitmessageqt/newsubscriptiondialog.py
Analyzing PyBitmessage-master/src//bitmessageqt/newchandialog.py
Analyzing PyBitmessage-master/src//debug.py
Analyzing PyBitmessage-master/src//message_data_reader.py
Analyzing PyBitmessage-master/src//class_outgoingSynSender.py
Analyzing PyBitmessage-master/src//namecoin.py
Analyzing PyBitmessage-master/src//class_sendDataThread.py
Analyzing PyBitmessage-master/src//bitmessagemain.py
Analyzing PyBitmessage-master/src//class_objectHashHolder.py
Analyzing PyBitmessage-master/src//depends.py
Analyzing PyBitmessage-master/src//api.py
Analyzing PyBitmessage-master/src//l10n.py
Analyzing PyBitmessage-master/src//helper_startup.py
Analyzing PyBitmessage-master/src//addresses.py
Analyzing PyBitmessage-master/src//helper_sql.py
Analyzing PyBitmessage-master/src//proofofwork.py
Analyzing PyBitmessage-master/src//singleton.py
Analyzing PyBitmessage-master/src//class_addressGenerator.py
Analyzing PyBitmessage-master/src//class_singleWorker.py
Analyzing PyBitmessage-master/src//defaultKnownNodes.py
Analyzing PyBitmessage-master/src//build_osx.py
Analyzing PyBitmessage-master/src//helper_bitcoin.py
Analyzing PyBitmessage-master/src//qidenticon.py
Analyzing PyBitmessage-master/src//shared.py
PyBitmessage-master/src//socks/__init__.py:218: High: gethostbyname
PyBitmessage-master/src//socks/__init__.py:283: High: gethostbyname
PyBitmessage-master/src//socks/__init__.py:323: High: gethostbyname
DNS results can easily be forged by an attacker (or arbitrarily set to large values, etc), and should not be trusted.
PyBitmessage-master/src//class_singleListener.py:75: High: compile
PyBitmessage-master/src//depends.py:112: High: compile
Argument 1 to this function call should be checked to ensure that it does not
come from an untrusted source without first verifying that it contains nothing
PyBitmessage-master/src//class_sqlThread.py:273: Medium: choice
PyBitmessage-master/src//helper_startup.py:103: Medium: choice
Standard random number generators should not be used to
generate randomness used for security reasons.  For security sensitive randomness a crytographic randomness generator that provides sufficient entropy should be used.
PyBitmessage-master/src//class_outgoingSynSender.py:48: Medium: seed
PyBitmessage-master/src//class_outgoingSynSender.py:54: Medium: seed
PyBitmessage-master/src//shared.py:159: Medium: seed
Standard random number generators should not be used to
generate randomness used for security reasons.  For security sensitive randomness a crytographic randomness generator that provides sufficient entropy should be used.
PyBitmessage-master/src//bitmessagemain.py:158: Medium: signal
When setting signal handlers, do not use the same function to handle multiple signals. There exists the possibility a race condition will result if 2 or more different signals are sent to the process at nearly the same time. Also, when writing signal handlers, it is best to do as little as possible in them. The best strategy is to use the signal handler to set a flag, that another part of the program tests and performs the appropriate action(s) when it is set.
See also: http://razor.bindview.com/publish/papers/signals.txt
PyBitmessage-master/src//class_objectHashHolder.py:39: Medium: randrange
PyBitmessage-master/src//class_objectHashHolder.py:42: Medium: randrange
PyBitmessage-master/src//class_singleWorker.py:99: Medium: randrange
PyBitmessage-master/src//class_singleWorker.py:176: Medium: randrange
PyBitmessage-master/src//class_singleWorker.py:269: Medium: randrange
PyBitmessage-master/src//class_singleWorker.py:384: Medium: randrange
PyBitmessage-master/src//class_singleWorker.py:587: Medium: randrange
PyBitmessage-master/src//class_singleWorker.py:861: Medium: randrange
PyBitmessage-master/src//class_singleWorker.py:907: Medium: randrange
PyBitmessage-master/src//shared.py:64: Medium: randrange
Standard random number generators should not be used to
generate randomness used for security reasons.  For security sensitive randomness a crytographic randomness generator that provides sufficient entropy should be used.
PyBitmessage-master/src//shared.py:426: Medium: stat
A potential TOCTOU (Time Of Check, Time Of Use) vulnerability exists.  This is
the first line where a check has occured.
The following line(s) contain uses that may match up with this check:
460 (chmod)
Total lines analyzed: 16932
Total time 0.083209 seconds
203487 lines per second

Uncategorized

Dirty Corporations and Financial Surveillance: Coming Soon to a Currency Near You

“Enlightened rulers and good generals who are able to obtain intelligent agents as spies are certain for great achievements.” — Sun Tzu, The Art of War

Journalists working with Edward Snowden came under fire last year under allegations of selling out to corporations and government interests, withholding documents leaked by Snowden that implicated corporations like PayPal in mass surveillance schemes. Critics suggested that Glenn Greenwald and Laura Poitras had been included in a $250 Million business partnership with PayPal’s CEO as hush money to keep damning evidence held by Greenwald and Poitras out of the public eye. Subsequent investigations into these allegations turned up a number of chilling comments made by National Security Agency insiders and experts.

“The NSA has had the cooperation of major financial institutions, including credit card companies, to obtain all financial transactions of these companies’ clients-international and domestic. Further, the NSA not only obtains and stores the financial data of Americans and foreigners, but it also shares them with other government agencies such as the FBI and DEA.” — William Binney, former top NSA official

“For NSA, information from financial institutions such as PayPal is equally if not more valuable and sought after than that obtained from social media and other software companies such as Facebook, Microsoft and Google. […] I wouldn’t doubt the existence of evidence and documents implicating corporations such as PayPal within the large cache obtained by Edward Snowden. The partnership and data collection arrangements have existed for many years.” — Russell Tice, former NSA Intelligence Analyst and Capabilities Operations Officer

fmr-nsa-russ-tice

Outside critics of government financial surveillance agree:

“Government access to financial transactions has always been top priority for all government agencies, worldwide. Nothing is more important to governments than where the money is, especially money for taxation required to avoid death-stake in the heart of governments. So it is consistent that NSA (and other spies) have access to all on- and off-line financial services providers. As you know, financial services are required to cooperate with their governments, perhaps second only to defense industries, perhaps first due to the need to track worldwide arms sales. Control of arms means control of wealth, and nothing is more appreciated by the few wealthy to offload arms cost to millions of taxpayers.” — John Young, Cryptome.org

You can read more about PayPal surveillance scandal here.

Financial corporations like PayPal have not only been supporting government surveillance of their customer’s finances, but also participating in blockades. In 2011, PayPal froze donations to WikiLeaks under pressure from the federal government. Not long after, they cancelled an account for a Chelsea Manning support fund, before a trial to judge her alleged war crime whistleblowing activities ever took place.

1E1F3670-020D-4517-9BE6-5B0AA7C0D12B_w640_r1_s

While some corporations take strategic advantage of these surveillance partnerships, others are merely held hostage by hostile governments with expectations of cooperation. In a recent blog post entitled, “Can any software from the United States be safe?” Monetas CTO Chris Odom explained the fears that motivated him to move his company and family from Texas to Switzerland. Odom cites threats to Yahoo CEOs for imprisonment and the coerced shutdown of Lavabit’s encrypted mail service as examples of how companies based in the US are forced to become part of the government’s surveillance apparatus.

As much as Bitcoin shows great promise in returning financial privacy to the consumer, threats to US companies remain a potent risk to Bitcoin’s promise in this realm, given how many important Bitcoin corporations remain under the umbrella of the US government. Coinbase, BitPay, Circle, and Cryptsy — just to name a few — are all US-based companies that collect sensitive financial data about Bitcoin-using consumers. Based on the clear evidence of willing collusion of corporations like PayPal, and the reluctant cooperation of others like Yahoo, consumers should assume that these companies are providing sensitive, privacy-damaging information about their customers to the surveillance state.

It’s up to cypherpunks to create the next generation of privacy friendly solutions to free us from this shadow. We need better anonymity protections in crypto-currency software, and decentralized exchanges to make surveillance less effective and far more expensive. Similarly, it’s up to Bitcoin users to protect their privacy to the best of their abilities by consuming privacy education resources and then practicing these newfound skills.

— Kristov

The Bitcoin Privacy Newsletter contains new posts and Bitcoin privacy tips from Kristov Atlas every week. Sign up and receive discounts on purchases of the Anonymous Bitcoin book.


Uncategorized

A Fistful of Bitcoins

Characterizing Payments Among Men with No Names

How much can you learn about Bitcoin users by simply engaging in transactions and data mining the blockchain? Researchers from UC San Diego and and George Mason University answered this question with a seminal paper published in 2013. From the paper:

“[Our goal is] to identify certain idioms of use […] that erode the anonymity of the users who engage in them.”

How were they able to achieve this goal?

“We engaged in 344 transactions with a wide variety of services, including mining pools, wallet services, bank exchanges, non-bank exchanges, vendors, gambling sites, and miscellaneous services.”

The researchers combined information they gleaned from these transactions with public sources of identifying information, such as Blockchain.info’s tagging service and the Bitcoin Talk forums. Armed with this database tying Bitcoin addresses to the names of individuals and businesses, the researchers applied heuristic algorithms to the full list of transactions provided by the blockchain, grouping related addresses together and associating previously unknown Bitcoin addresses with the ones the researchers had already identified.

What did the researchers conclude? The same thing that crypto-currency privacy advocates have been saying for years, now:

“Even our relatively small experiment demonstrates that this approach can shed considerable light on the structure of the Bitcoin economy, how it is used, and those organizations who are party to it.”

Bitcoin privacy is broken, and in desperate need of a fix. I’m sad to report that, although this research was published in late 2013, we still have not seen a software fix for these issues. It’s up to users to educate themselves on the art of obscuring their funds from the world.

If you’d like to learn more about the research, but aren’t attracted to the idea of reading an academic paper, check out this video presentation on the research, filmed at the University College of London on October 17th:

The Bitcoin Privacy Newsletter contains new posts and Bitcoin privacy tips from Kristov Atlas every week.


Uncategorized

Interview: The Crypto Show

The Crypto Show has a new vision for liberty minded people these days, crypto-anarchism.  Abandoning the model of “waking up” 51% of the fat-bellied uninterested and distracted public, The Crypto Show crew hope to inspire the smartest 1% to create open-source, distributed systems of resistance to render the state irrelevant through technology and encryption.

Harlan, Ryan, and Martin had me on the show last Sunday to discuss a range of topics including:

  • Why I got into Bitcoin
  • What are my biggest concerns about Bitcoin right now? (Hint: privacy)
  • My book, Anonymous Bitcoin
  • How Bitcoin can help people circumvent unfair capital controls
  • The Ross Ulbricht case and parallel construction
  • Silk Road and the legacy of the Dark Market Transition Economy

Finance cryptography expert Justus Ranvier joins me part-way to discuss why Bitcoin’s network effect is different from social networks, and much more.

      http://mp3.logosradionetwork.com/CRYPTO/64k/CRYPTO_2014-10-12_64k.mp3
Darkcoin

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 0.10.13.10 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 0.9.12.32. 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.

https://github.com/darkcoinproject/darkcoin/commits/master?author=rebroad

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:

init.cpp:
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.

Uncategorized

[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]

-Kristov

Uncategorized

Visualizing One Round of Darkcoin’s DarkSend+

I’m currently performing a security and privacy review of the not-yet-open source code of DarkSend+, the privacy technology implemented in the Darkcoin crypto-currency. This effort has been crowd-funded by the generous Darkcoin community.

In the coming weeks, I will be releasing information pertaining to this review. I’m kicking the process off with a diagram, explaining in broad terms how DarkSend+ works, aimed at those not already familiar with the technology.

DarkSend+, an iterative improvement on Darkcoin’s previous DarkSend technology, is a CoinJoin-based technology that allows Darkcoin users to mix funds with each other. This functionality is built directly into the reference Darkcoin wallet software. CoinJoin takes advantage of the fact that Bitcoin transactions are not limited to a single sender or receiver; in fact, DarkSend+ transactions often involve two or more senders. Previous CoinJoin implementations have been limited in that they require senders to meet at the same place and time on the Internet at the moment they are prepared to send other users money. DarkSend+ skirts around this limitation by mixing funds passively, according to user-specified parameters, in the background; when the user is ready to send anonymized funds to his recipient, the funds have long since been mixed and no further work is required. This approach provides Darkcoin clients a marketplace of funds to mix with at everyone’s leisure, rather than desperately seeking out (and waiting for) other willing and compatible clients at the last moment.

Users can select how many rounds of DarkSend they want their funds to go through in order to be considered “anonymized.” The more rounds, the more privacy the user will have, but more rounds will also expend more transaction fees and time. The user will also instruct the client about how much of their funds they wish to be anonymized. The Darkcoin wallet keeps track of how many rounds of DarkSend funds have gone through in order to meet the user’s standard, and will not allow the user to do an “anonymous” send before that qualification has been met.

The diagram below shows the flow of my funds (indicated in blue) as they go from a Darkcoin testnet faucet payout of 1000 DRK through a single round of DarkSend+ for 100 of those DRK. By the end, those DarkSent coins will be mixed with other users’ (indicated in red). Before that begins, there’s a “splitting” phase that takes place in which the 1000 DRK is broken down into smaller chunks more suitable for the denominations that are compatible with the DarkSend process.

 

darksend_testnet_2014_08_19_verb(4)
(Click to view full size.)
Uncategorized

Amir Taaki on Threats to Bitcoin’s Principles

“So tell me, why should I embrace these white knights coming to legitimise Bitcoin with their surveillance and censorship palming it off with their gibberish newspeak. These people are real motherfuckers and what motivates them primarily is greed at your expense.

They don’t see Bitcoin as empowerment. They see Bitcoin as convenience, and are willing to compromise the empowerment aspect for more convenience. Bitcoin will grow, but the question is in which direction.

[…]

It’s funny because all this talk of Bitcoin as being politically-neutral is a way of downplaying the values I’ve been talking about above. You can never be politically neutral. That’s a fantasy. Technology embodies values. Satoshi had values.”

“If you still don’t believe that features can be developed that are against small business, p2p transfers and the blackmarket, but pro consumers and corporations then see Mike Hearn’s last proposal for improving the security of 0conf payments with the unfortunate side effect of enabling miner blacklists.

And this is just the most malicious and prescient example. The vast majority of proposals are non-controversial and non-noticeable to most people. But don’t forget, it’s the sum of those decisions that affects Bitcoin. And it’s not enough that Bitcoin is opensource. We actually need participating developers who understand these issues deeply. That’s why I’m so glad we have people like Peter Todd, who really see things deep and understand the true social, political and technical ramifications of our decisions that the 99% majority of developers (myself included) don’t see.”

—Amir Taaki