Gavin Andresen, the former lead developer of bitcoin, is breaking his silence.
While in recent months he’s been more active on Twitter discussing the block size debate (even stamping his name on a new bitcoin scaling ‘agreement’), Andresen has largely been absent from the bitcoin developer community for about a year.
But, that doesn’t mean the prodigious worker, who did much to help build out bitcoin’s early developer team and market, hasn’t been busy.
At the beginning of May, Andresen tweeted:
I’m looking for beta testers and collaborators for my Random Sanity Project: httpss://t.co/NEbpr1baqk
— Gavin Andresen (@gavinandresen) May 1, 2017
The project looks to better secure the internet by checking sources of randomness used by individuals and organizations.
Keeping an eye on bitcoin
The Random Sanity Project not only stemmed from Andresen’s interest in learning the programming language GO, but also in seeing the problems a lack of entropy can have in monetary software systems like bitcoin.
“I certainly still do keep up with bitcoin,” Andresen told , adding that he might contribute code review to DCG’s new bitcoin scaling proposal, but that he’s unlikely to write any of the code.
“Bitcoin is such an interesting project because it’s security critical,” he said. “If the security fails, it’s immediately obvious, people lose money and react immediately.”
This is different, he continued, than an email account being taken over or attacked, in that people typically don’t notice those breaches for some time.
“For a lot of security issues, bitcoin brings them into the light,” Andresen said.
This quick reaction was seen in several mishaps based on faulty random number generation in the bitcoin ecosystem.
In May 2015, a vulnerability in Blockchain’s Android bitcoin wallet left several users out money. According to , the vulnerability allowed duplicate bitcoin addresses to be created and given to different users. At its core, the problem was with Blockchain’s random number generator, random.org, which provided insufficient entropy on certain versions of the Android operating system.
And two years before, in August 2013, all bitcoin wallet applications on Android operating systems were potentially at risk when several vulnerabilities were found within another random number generator, Java SecureRandom.
Maintaining a distance
While the project is definitely tangential to Andresen’s former work as bitcoin’s lead maintainer, it’s also much different.
“So far, it’s a one-person project, which I like,” Andresen told . “It’s nice and simple. I chose something small and intentionally boring.”
“Bitcoin was a big, complicated project involving lots of people spread out all over the world; there was too much stress and politics and I didn’t want that again.”
Andresen has been working on the Random Sanity Project for about six months. According to him, the project is not intended to be a profit-making business. Instead, ideally, the project would be sponsored by an entity like the Linux Foundation to offer the service to anyone for free.
So how does Random Sanity work? Every system and every programming language has a way of getting random bytes – for instance, Linux has a special folder called ‘/dev/urandom’ and OpenSSL provides several random number generators (which Bitcoin Core uses).
Users of the Random Sanity Project can take those random numbers – from 16 to 64 bytes – and input them into the service, which will return a ‘true’ if the bytes look random, or a ‘false’ if the numbers don’t.
“The problem of detecting whether your random numbers are good enough is a tricky problem,” Andresen told . “There are a bunch of ways you can screw up.”
Digital health check
While random number generators are created specifically to provide entropy (a lack of order, and hence predictability), there are several reasons something might go wrong.
Software downloads and upgrades can mess with randomness. Or it can be as simple as someone tripping over the virtual machine utilizing a random number generator cord and unplugging it.
But a typical failure, Andresen said, is when an organization is using cloud computing and starts up multiple virtual machines at the same time.
In this case, the organization might save an image of the software and run multiple copies for the web servers that handle traffic. Because the virtual machines are starting in the same state, they could, according to Andresen, come up with the same ‘random’ numbers.
“There are usually tools for increasing entropy so this doesn’t happen,” he said, “but [the Random Sanity Project] could be a good check.”
While he doesn’t think a company needs to run every string of bytes a machine gives them through the tool, it would be beneficial to send one string of bytes when the machine starts up to make sure it’s generating reasonable randomness. Then, he said, if it fails, the problem can be investigated.
“This is designed as a way to make sure catastrophic disasters don’t happen, or you catch them quick enough,” said Andresen.
Further, the more people and organizations that use the system, the more valuable it becomes, because it can then base randomness on many more strings of bytes.
Currently, though, only a few have beta tested the service, sometimes contributing code back to the project – including people from startups Blockchain and ShapeShift, according to Andresen.
The trustless trend
On Twitter, some praised the service, while others were worried about the system’s architecture.
For one, the initial system used HTTP, which allowed anyone to eavesdrop and see the random bytes being sent to the system. Andresen quickly relaunched using HTTPS to provide a secure connection so that no one can see what bytes are sent.
If an entity’s random number generator is broken, seeing one supposedly random string of bytes could open that entity up to attack, said another complaint from a Twitter user. A chance worth taking, Andresen responded.
As far as Andresen having insight into the bytes being sent to the service, he said he has none.
And, following the trend set by bitcoin, he said:
“I’m trying to arrange things where people don’t have to trust me.”
While the service is currently running on the App Engine of the Google Cloud Platform, his next project is opening the project up to allow auditing by third parties. Presently, people can only audit the open-source code on GitHub, which Andresen assured , is exactly what’s running on the App Engine. The extra step, though, will prove it