Votebook – A proposal for a blockchain-based electronic voting system [pdf]

Essentially votes can be cast on every subject (for the very interested voters), or delegated to another representative (for the less interested voters).

This could have some interesting side-effects, not all positive; I'd expect volatility and cult of personality to increase. But then that's the trajectory of politics in general recently, so perhaps there's not much more to lose. Benefits would include the ability for voters to actually enact the legislation that they want, but which no legislators will choose to implement (e.g. anti-corruption/insider trading laws).

[edit: link is here: http://www.tdcommons.org/cgi/viewcontent.cgi?article=1092&co...]

The first clause of Design Considerations, "Although elegant and (thus far) invincible," shows a lack of understanding of currently possible and prior blockchain attacks.

This protocol allows voting any Voter ID multiple times. There is a significant window of time until one of the blocks containing the Voter ID/ballot ID Hash is added to the block chain. During this time, all Voter IDs in the prospective block may be voted multiple times. This can occur by making a copy of a physical voter ID and simply using it twice at relatively the same time - just not on the same terminal. The exploitability chance increases as the number of votes per block increases. The blockchain plus the union of all unsent blocks for all terminals, not a local database, should be checked for who has voted. This is compounded by not checking when the blocks are added to the blockchain.

Another issue with the local database, is that even if it is made to be a site database, many jurisdictions with early voting allow voters to vote anywhere, not just at their assigned voting location.

The selected candidates are not signed properly with a voter's key. There is no assurance that a particular voter actually cast a vote for a specific candidate and not, say, "Mickey Mouse." This is actually one of the purposes of smart cards and similar. Beyond any protocol issues, this is the central purpose of any voting system, to ensure that when votes are cast the voter id is redacted but that that voter id's candidate selection can be validated!

The Central Admin should release the list of the machine's public keys _prior_ to the election not _after_.

There really are a lot of security issues with this security design.

That being said, this paper is the winner of a cyber challenge here: http://www.economist.com/whichmba/mba-case-studies/cyber-sec...

And you don't have to put in the backdoor just for the election. You can put one in and use it opportunistically. Someone backdoored a huge amount of Juniper VPN hardware, in hopes that it might be useful some day:

http://arstechnica.com/security/2016/01/juniper-drops-nsa-de...

And to answer your question, this is how you get silicon like a CPU to do what you want:

https://www.schneier.com/blog/archives/2012/05/backdoor_foun...

These are just two examples that made the news. It's a practical certainty that there's backdoors in all sorts of COTS components that we don't know about yet. At this point there's nothing above suspicion.

For the scheme in TFA to work, they need a unhackable computer. If there is a single exploit or backdoor that happens to be in it, whoever controls it can pick the US congress, the senate, and the POTUS. Not metaphorically, literally. How is taking that degree of risk, when you know that backdoors and exploits are commonplace, not incredibly foolish?

I work with government often. I am often outside begging to be given access to help my community with one civic project or another. Interactions that take hours in open source communities, take months to coordinate with City staff.

I'm the last one to advocate taking the brakes off the car, but there are many many many parts of government where decisions require several years only because everything takes years to do. I think there is a perspective, if you step back to imagine this world, where we as citizens can participate and make the turn-around quicker. Not everywhere. Many government functions require care and caution and sober second/third/fourth thoughts.

But many of these actions need not take years, if we could re-imagine something better. And right now, the lifeblood of government runs like molasses, not because each slow process has been intentionally made slow, but because the processes and practices and hierarchies are structurally slow at their core. That's not clever slowness. That's a calcifying fossil.

I personally think giving citizens more decision-making access will keep civil servants on their toes, keep them learning, and speed up the cycle time in many needlessly slow areas of government.