For the past couple weeks, I’ve been reading crypto fiction and essays, starting with True Names by Vernor Vinge. His vision was revolutionary for its time, and still inspires with its imagery of warlocks and witches, spells and incantations (of course, it’s all code in the real world).
I also read “True Nyms and Crypto Anarchy” by Timothy May in the same collection, most of which I did not agree with. His vision of a crypto-anarchist/libertarian “utopia” is misguided at best, and dangerous at worst — without delving into and getting sidetracked by politics, libertarians ignore the fact that their system would leave many out in the cold, the fact that the market doesn’t give a shit about people compared to profits. In short, it would be chaos for many. It would take another, lengthy post to dive into the details, but suffice it to say that the “crypto-anarchy” May describes is not desirable for most.
The most important essay I read, however, was “From Anonymity to Identification” by A. Michael Froomkin. To quickly summarize, privacy is in grave peril, both in the digital and real worlds. I’d highly recommend reading the paper, but the takeaway for me was that something has to happen now. Someone has to write the code to make privacy viable in the digital age now. I can’t just sit around and hope someone else will do it, so it might as well be me.
So, with this context in mind, I set out to begin coding a pseudonymous publication system for journalists based on the work of David Chaum, using the Dining Cryptographers protocol and “mix networks”, among other techniques building on the “web of trust” originating in PGP. As promised before, a post detailing the system is forthcoming.
The first choice I had to make was: which language should I write this in? This choice was largely limited by which cryptography libraries I decided to use. An article by Thomas Ptacek (whom I very much admire and respect) suggested Google Keyczar or cryptlib. Keyczar is out from the get-go, simply because I don’t trust Google not to insert backdoors into their products at the request of a three-letter agency. As for cryptlib, I’m wary: I don’t know when the library was last updated, the license is a concern, and links to the zip file itself are outdated and appear to be broken.
At this point, I’m looking at libgcrypt, a library developed by the folks behind GnuPG. Its bindings are in C, like cryptlib, so I was torn between the choice of C, or a language with a solid FFI. I bought a book on C, Learn C the Hard Way by Zed Shaw, although as I quickly discovered firsthand, C is a dangerous language. As I’ve heard for years, since I started learning to code, C is fraught with buffer overflows, memory handling issues, and other security concerns that make it exceedingly difficult to write safe code in C.
So, which language should I use? I considered the possibilities: C and C++ were out, for security reasons; both Java and C# are undesirable, as the JVM and .NET respectively are both closed-source in their most widely used implementations; and Python seemed like a reasonable choice, but the GIL makes it too hard to write concurrent code in a reasonable fashion. What does that leave me with?
It was at that point that I remembered Rust. It’s developed primarily by Mozilla, one of the few companies I trust. It has an excellent ecosystem, gaining popularity by the day. Most importantly, its compiler guarantees memory safety and easy-peasy concurrency, it’s “blazing fast”, and it has a reasonable FFI for interfacing with C libraries. With these benefits in mind, I’ve started reading the official book, The Rust Programming Language, freely available on the official site.
I’m afraid. I’m afraid I don’t have the coding chops to pull this off. I’m afraid I can’t do it. I’m afraid, most of all, that I’m going to fuck up the crypto code and introduce a subtle bug or vulnerability that will be discovered after the fact. So, the plan is to release an open source alpha as soon as humanly possible, and solicit cryptography experts to audit the code, try it out, to see what breaks and what works. At the same time, I hope to recruit better developers than myself to work on the code. Finally, I am going to meticulously study the Signal codebase for inspiration and guidance.
My hopes are slim. As Froomkin describes, privacy, both in the digital world and in real life, is rapidly dwindling. There are many arguments against privacy, in fact, in the post-9/11 age, mainly centered around the dangers that guaranteed, unbreakable privacy poses.
There’s an interesting solution proposed by David Chaum that essentially allows users of the system to “out” bad actors. Using the Dining Cryptographers protocol, that’s certainly possible. But these issues are not my main concern — my concern is that I’m going to write buggy code, that I’m going to create an ultimately broken system, that I’m going to create a system that costs lives rather than saving them.
Even so, I have to try.