Fully software, even a combo of software and hardware, cannot by itself make elections secure. Think of the On Trusting Trust problem, the need to verify firmware, etc. You can't ensure that machines _will_ work correctly, but you _can_ verify that they _did_. To do verify the machines' functioning after the fact you have to do it very soon after closing of the polls, and you have to devise a manual, statistical random sampling method where you manually check randomly sampled, marked paper ballots, against the digital cast vote record, then do a digital risk limiting audit to check that the CVR totals up to the machines' reported results. The sooner after closing of the polls you do this, the better the likelihood that any cheating will be caught. I.e., an immediate manual, partial audit of enough randomly-selected polling locations.
That still leaves tons of other technical problems to address, like security of mail-ballots / absentee ballots, the security of ballot boxes used for early voting (because you probably cannot run the above manual partial audit due to then having nightly results available to the public; or maybe you accept that), etc.
Your ID card contains a private key, you use that key to sign a transaction. It doesn't matter that machine you are running on is compromised as these details can be verified at a later date.
Example A:
You vote for candidate A, but software changes to candidate B and software displays that you voted for candidate A. At any later time you can check with an independent device and look at the transaction finding out that it was altered with and retract your vote / change it.
Example B:
How do you know your vote was counted? Publish a hash and the signature of every vote, recompute the final tally and compare with all the votes. If your vote is not in the final tally the hash will be different and you can visibly see your vote in the dataset as every transaction is published. To preserve privacy each round has a number, private key + number -> new key so each fingerprint will be unique between votes.
I've spent a lot of time thinking about this problem, and my conclusion is that cryptography alone is not the solution, for reasons like:
1. The public needs to believe it, and hypertechnical solutions are a hard sell.
2. Any blockchain approach needs to preserve the secrecy of the ballot, otherwise you get all the problems you can expect of non-secret votes (coercion, vote buying, shaming network effects).
3. You still need to have the cryptographic rubber meet the physical road _somewehere_ -- it has to, otherwise the need for vote secrecy means that the results can be entirely fictitious and pre-programmed and there is no way to check!
I.e., you can have a paperless blockchain solution IFF you abandon vote secrecy. That is a very tough to swallow pill.
On the other hand, if you accept paper ballots and manual partial audits as part of the solution, then blockchain can have a role to play. For example, the machines could display a blockchain head every 50 ballots cast, and voters take a copy of the blockchain head visible to them, then after the election the public can verify the integrity of the blockchain, and the fact that you only get running tallies every 50 ballots means you get vote secrecy.
A system that uses paper ballots and partial manual audits can be explained to the public, and the public can develop confidence in it. Blockchains can then add a good deal of confidence: the blockchain tells you that the tallies were not modified after the fact, and the partial manual audit tells you to an acceptable level of statistical confidence that the digital cast vote record contains the actual paper ballots _as marked and cast_ by voters.
>I.e., you can have a paperless blockchain solution IFF you abandon vote secrecy. That is a very tough to swallow pill.
This is false. I know this is a common thought here on HN because some formerly popular youtuber did a video about this that was regularly reposted here, but he was wrong in theory back then and it is wrong in practice today. Secrecy and anonymity and verifiability are no longer mutually exclusive as anyone who is well versed in modern cryptography will be able to tell you.
I'd appreciate some references. That's not because I'm trying to put you down with a request for references, but clearly you have seen them, and I'd like to see them.
I agree that convincing the public is another issue. But on a technical level, these problems are solved. See e.g. this implementation: https://github.com/vocdoni/davinci-paper
There is no problem that electronic voting solves that paper ballots and scanners do not, and the latter are not only more secure but are seen to be more secure. Trust is essential in a voting system and only paper ballots provide the necessary level of trust.
Who makes your ID card, generates the private key, and stores it there? Do you trust them? Did they retain a copy of the key? Did they implement security effectively (a very difficult task, considering the resources of attackers)? What about securing the manufacturing process?
So if someone else knows my private key and voted for me not the same way i intended to vote, this will be visible in final results. And then you can start asking questions. If they have my private key and voted the way i intended, then its no problem :)
> Example A: You vote for candidate A, but software changes to candidate B and software displays that you voted for candidate A. At any later time you can check with an independent device and look at the transaction finding out that it was altered with and retract your vote / change it.
This seems to make a pretty dramatic change to the election protocol, no?
Consider example A': You vote for candidate A, but later realize that you hate candidate A. You repudiate your recorded vote for candidate A.
How much later? Cryptographic systems certainly have methods for allowing revoting up to a deadline, but endlessly mutable voting is insane. It's also not really any different from today. I can say I didn't vote for candidate A 12 months after the upcoming election and it means... well... nothing.
> Think of the On Trusting Trust problem, the need to verify firmware, etc.
I mean that's too abstract and philosophical of a problem when talking about voting machines/software: there are much more prevalent and concrete risks including but not limited to APT-grade breach/espionage if your country is important enough, and the various other issues (some in your comment itself).
Yes, of course. See my reply to sibling comment about why a software solution is insufficient, even a soft/hardware solution is insufficient. Cryptography does not save the day. A modicum of physically auditable paper trail is required.
There are a lot of folks who, whenever this topic comes up, seem to have no knowledge of the systems which already exist and have actually been used in real elections already. For instance, ElectionGuard has been used in several real elections in the US since 2020[1].
There's issues that are pretty fundamental with the black-box approach that the electronic ballot becomes. Paper and transparent ballots can be scrutinized pretty easily, but once you have a black box that might also be connected to the internet there's nothing you can really trust.
> The intention behind this repository is to make source code of the Estonian online voting system available for public review.
> The repository is not used for active development, but will be kept up to date, so the code that can be found here is the code that is used for election.
The repository is not used for active development, but will be kept up to date, so the code that can be found here is the code that is used for election. As the voting system used for legally binding elections must strictly follow the legislation, the actual development of Estonian I-voting system and I-vote verification application is supervised by State Electoral Office of Estonia. Please refer to www.valimised.ee for further information.
But updates are promised, so GP's question is valid: where are they, and since they're not there, why? Is this the final product's source code and it has not been modified since?
I know the answer is "you don't", but suppose I vote vote electronically for candidate A. In the end, the candidate loses with 764 votes. How do I convince myself that my vote was counted in the 764 votes, and that it was not a randomly chosen number (with a RNG skewed around "plausible" scores) ?
There is a separate verification tool I've used that lets me confirm who I voted for, and that the server has registered my vote. Also, like in elections in other places, every election has observers take part. OSCE regularly send their lot, their report on the last parliamentary election can be read here https://odihr.osce.org/odihr/elections/estonia/551179.
To take it one step further: how does the election authority convince everyone that their vote was counted?
Us "computer folks" convincing ourselves is the easy part. Maybe after enough studying of the system, I'd be absolutely sure that my vote was counted, but what would the other 90 % of the population think? This not a "people are stupid" argument, a brain surgeon or nuclear physicist or philosopher isn't going to put in the effort to understand fully homomorphic cryptography, hardware-based security, etc. Why should they?
The alternative works perfectly fine and it's so easy to explain. It's obvious to anyone, no matter their level or field of education, how their vote makes it from their hand into the tally, what prevents it from being misused and what they can do to further reduce that already tiny probability.
You can see, feel and experience the technical measures keeping your vote safe. The people keeping their eyes on the ballot box alp day may literally be your neighbours, as are the people counting. You can reason about their motivations, you can theorise in your head about what lengths you'd have to go to in order to change even a few votes and how unlikely you would be to succeed.
The biggest danger to elections, ultimately, isn't the risk of cheating. It's the risk of losing the people's trust.
(I'm in the local election commission (that's layer 2 out of 4 in our particular election management hierarcy), we just had a big referendum, everyone keeps asking me about online elections so this rant was fresh on my mind)
I think this is an easy enough problem to solve, the issue is that someone else can how force you to reveal who you voted for. Spouse, rouge employers, mafia, corrupt politicians. You can now "sell" your vote.
I think such a system could still work, but just like the voter has to go to the booth alone to vote, they must go the booth alone to verify.
In any system, I suspect it is possible. There are strategies that allow doing private set intersections (or similar): https://en.wikipedia.org/wiki/Private_set_intersection (i.e. a set with one member is "you", and you can check to see if you're in that 764, without knowing who the others are)
I'm not sure what strategies would also allow you to not reveal to the vote collectors where your vote went, but there might be something.
> Private set intersection is a secure multiparty computation cryptographic technique[1] that allows two parties holding sets to compare encrypted versions of these sets in order to compute the intersection. In this scenario, neither party reveals anything to the counterparty except for the elements in the intersection.
Revealing even elements in the intersection, if that means revealing individual votes, breaks ballot secrecy.
You convince yourself the way you do with any elections: you trust the people/system that counts the votes. If you think about it for a second, the requirements of a secret ballot (meaning it's not possible to know who voted who) and the fully verifiability you are asking for are mutually exclusive. You can have either one but not both at the same time.
That being said I think the Estonian voting system does a decent job of being trustworthy. Publishing the source code is a big step to the better as well. As far as I knew the system was written in Java but seems like they have upgraded it in Go. Good job! Probably the best in the world.
All the source code in the world means nothing when it comes to elections. It's the object code, down to firmwares, BMCs/MEs, even microcode that matters. It's hard to establish trust in those things.
I wouldn't say it means nothing, but you are right in that it is not a silver bullet. It is one piece of a chain of custody to build the trust. Having source code is better than not having it. Having verifiable builds is better than not having them. Having trustworthy hardware is better than not having it. You get the gist?
In practice too. Elections are worth up to trillions of dollars. That means that agencies like state-level actors, and private actors with the necessary resources, will be tempted to mount supply chain and other attacks, and likely will succeed.
Faking paper ballots is totally doable, but you can take various precautions to make that very difficult. For example, you can deliver ballots to polling locations in sequentially-numbered packs and shuffle them at the voter sign-in desk: by shuffling the packs before delivery, by having the elections judges record which packs they got and which numbers went unused, by making them sign ballots prior to placing them on the sign-in table, and so on, you can make it very difficult for elections administration staff to later replace those paper ballots. But you're going to need timely, partial or full hand-count audits in order to make it necessary to replace paper ballots in order to replace results.
Election security is pretty expensive, but compared to the _value_ of elections, it's nothing.
In a paper election, you have a chain of people who supervise each other. Depending on where you live, you can volunteer to be part of that and see it for yourself.
In code, you have no insight into what actually happens.
Let's say you encounter a mob society that is convinced that there is a very high risk of election fraud and will apply unnecessary scrutiny to votes, a little rip in the paper or ink not matching standards.
trivia: did you know that a tear in any of the pages of your passport renders it invalid?
Logic tests only show that the machines worked correctly as of the logic test. It's easy enough to design them to behave correctly in all cases except actual elections.
Fully software, even a combo of software and hardware, cannot by itself make elections secure. Think of the On Trusting Trust problem, the need to verify firmware, etc. You can't ensure that machines _will_ work correctly, but you _can_ verify that they _did_. To do verify the machines' functioning after the fact you have to do it very soon after closing of the polls, and you have to devise a manual, statistical random sampling method where you manually check randomly sampled, marked paper ballots, against the digital cast vote record, then do a digital risk limiting audit to check that the CVR totals up to the machines' reported results. The sooner after closing of the polls you do this, the better the likelihood that any cheating will be caught. I.e., an immediate manual, partial audit of enough randomly-selected polling locations.
That still leaves tons of other technical problems to address, like security of mail-ballots / absentee ballots, the security of ballot boxes used for early voting (because you probably cannot run the above manual partial audit due to then having nightly results available to the public; or maybe you accept that), etc.
You solve all of these with cryptography.
Your ID card contains a private key, you use that key to sign a transaction. It doesn't matter that machine you are running on is compromised as these details can be verified at a later date.
Example A: You vote for candidate A, but software changes to candidate B and software displays that you voted for candidate A. At any later time you can check with an independent device and look at the transaction finding out that it was altered with and retract your vote / change it.
Example B: How do you know your vote was counted? Publish a hash and the signature of every vote, recompute the final tally and compare with all the votes. If your vote is not in the final tally the hash will be different and you can visibly see your vote in the dataset as every transaction is published. To preserve privacy each round has a number, private key + number -> new key so each fingerprint will be unique between votes.
> You solve all of these with cryptography.
I've spent a lot of time thinking about this problem, and my conclusion is that cryptography alone is not the solution, for reasons like:
1. The public needs to believe it, and hypertechnical solutions are a hard sell.
2. Any blockchain approach needs to preserve the secrecy of the ballot, otherwise you get all the problems you can expect of non-secret votes (coercion, vote buying, shaming network effects).
3. You still need to have the cryptographic rubber meet the physical road _somewehere_ -- it has to, otherwise the need for vote secrecy means that the results can be entirely fictitious and pre-programmed and there is no way to check!
I.e., you can have a paperless blockchain solution IFF you abandon vote secrecy. That is a very tough to swallow pill.
On the other hand, if you accept paper ballots and manual partial audits as part of the solution, then blockchain can have a role to play. For example, the machines could display a blockchain head every 50 ballots cast, and voters take a copy of the blockchain head visible to them, then after the election the public can verify the integrity of the blockchain, and the fact that you only get running tallies every 50 ballots means you get vote secrecy.
A system that uses paper ballots and partial manual audits can be explained to the public, and the public can develop confidence in it. Blockchains can then add a good deal of confidence: the blockchain tells you that the tallies were not modified after the fact, and the partial manual audit tells you to an acceptable level of statistical confidence that the digital cast vote record contains the actual paper ballots _as marked and cast_ by voters.
>I.e., you can have a paperless blockchain solution IFF you abandon vote secrecy. That is a very tough to swallow pill.
This is false. I know this is a common thought here on HN because some formerly popular youtuber did a video about this that was regularly reposted here, but he was wrong in theory back then and it is wrong in practice today. Secrecy and anonymity and verifiability are no longer mutually exclusive as anyone who is well versed in modern cryptography will be able to tell you.
I'd appreciate some references. That's not because I'm trying to put you down with a request for references, but clearly you have seen them, and I'd like to see them.
Also, you still have to convince the public.
I agree that convincing the public is another issue. But on a technical level, these problems are solved. See e.g. this implementation: https://github.com/vocdoni/davinci-paper
Relevant xkcd: https://xkcd.com/2030https://xkcd.com/2030
There is no problem that electronic voting solves that paper ballots and scanners do not, and the latter are not only more secure but are seen to be more secure. Trust is essential in a voting system and only paper ballots provide the necessary level of trust.
Who makes your ID card, generates the private key, and stores it there? Do you trust them? Did they retain a copy of the key? Did they implement security effectively (a very difficult task, considering the resources of attackers)? What about securing the manufacturing process?
In the end, you always must trust humans.
So if someone else knows my private key and voted for me not the same way i intended to vote, this will be visible in final results. And then you can start asking questions. If they have my private key and voted the way i intended, then its no problem :)
Indeed. The rubber hose always beats cryptography. Always.
> Example A: You vote for candidate A, but software changes to candidate B and software displays that you voted for candidate A. At any later time you can check with an independent device and look at the transaction finding out that it was altered with and retract your vote / change it.
This seems to make a pretty dramatic change to the election protocol, no?
Consider example A': You vote for candidate A, but later realize that you hate candidate A. You repudiate your recorded vote for candidate A.
What should happen?
How much later? Cryptographic systems certainly have methods for allowing revoting up to a deadline, but endlessly mutable voting is insane. It's also not really any different from today. I can say I didn't vote for candidate A 12 months after the upcoming election and it means... well... nothing.
[delayed]
> Think of the On Trusting Trust problem, the need to verify firmware, etc.
I mean that's too abstract and philosophical of a problem when talking about voting machines/software: there are much more prevalent and concrete risks including but not limited to APT-grade breach/espionage if your country is important enough, and the various other issues (some in your comment itself).
Yes, of course. See my reply to sibling comment about why a software solution is insufficient, even a soft/hardware solution is insufficient. Cryptography does not save the day. A modicum of physically auditable paper trail is required.
There are a lot of folks who, whenever this topic comes up, seem to have no knowledge of the systems which already exist and have actually been used in real elections already. For instance, ElectionGuard has been used in several real elections in the US since 2020[1].
[1]: https://electionguard.vote/
Used in the real world doesn't mean it's secure.
There's issues that are pretty fundamental with the black-box approach that the electronic ballot becomes. Paper and transparent ballots can be scrutinized pretty easily, but once you have a black box that might also be connected to the internet there's nothing you can really trust.
The answer is paper backed by an ID, but i guess is too late for that.
Interesting that there are no updates for almost a year. Cool stable software, I guess?
Explanation is in the README:
> The intention behind this repository is to make source code of the Estonian online voting system available for public review.
> The repository is not used for active development, but will be kept up to date, so the code that can be found here is the code that is used for election.
from README
The repository is not used for active development, but will be kept up to date, so the code that can be found here is the code that is used for election. As the voting system used for legally binding elections must strictly follow the legislation, the actual development of Estonian I-voting system and I-vote verification application is supervised by State Electoral Office of Estonia. Please refer to www.valimised.ee for further information.
But updates are promised, so GP's question is valid: where are they, and since they're not there, why? Is this the final product's source code and it has not been modified since?
I know the answer is "you don't", but suppose I vote vote electronically for candidate A. In the end, the candidate loses with 764 votes. How do I convince myself that my vote was counted in the 764 votes, and that it was not a randomly chosen number (with a RNG skewed around "plausible" scores) ?
There is a separate verification tool I've used that lets me confirm who I voted for, and that the server has registered my vote. Also, like in elections in other places, every election has observers take part. OSCE regularly send their lot, their report on the last parliamentary election can be read here https://odihr.osce.org/odihr/elections/estonia/551179.
To take it one step further: how does the election authority convince everyone that their vote was counted?
Us "computer folks" convincing ourselves is the easy part. Maybe after enough studying of the system, I'd be absolutely sure that my vote was counted, but what would the other 90 % of the population think? This not a "people are stupid" argument, a brain surgeon or nuclear physicist or philosopher isn't going to put in the effort to understand fully homomorphic cryptography, hardware-based security, etc. Why should they?
The alternative works perfectly fine and it's so easy to explain. It's obvious to anyone, no matter their level or field of education, how their vote makes it from their hand into the tally, what prevents it from being misused and what they can do to further reduce that already tiny probability.
You can see, feel and experience the technical measures keeping your vote safe. The people keeping their eyes on the ballot box alp day may literally be your neighbours, as are the people counting. You can reason about their motivations, you can theorise in your head about what lengths you'd have to go to in order to change even a few votes and how unlikely you would be to succeed.
The biggest danger to elections, ultimately, isn't the risk of cheating. It's the risk of losing the people's trust.
(I'm in the local election commission (that's layer 2 out of 4 in our particular election management hierarcy), we just had a big referendum, everyone keeps asking me about online elections so this rant was fresh on my mind)
I think this is an easy enough problem to solve, the issue is that someone else can how force you to reveal who you voted for. Spouse, rouge employers, mafia, corrupt politicians. You can now "sell" your vote.
I think such a system could still work, but just like the voter has to go to the booth alone to vote, they must go the booth alone to verify.
In this system: I have no idea.
In any system, I suspect it is possible. There are strategies that allow doing private set intersections (or similar): https://en.wikipedia.org/wiki/Private_set_intersection (i.e. a set with one member is "you", and you can check to see if you're in that 764, without knowing who the others are)
I'm not sure what strategies would also allow you to not reveal to the vote collectors where your vote went, but there might be something.
From that wiki:
> Private set intersection is a secure multiparty computation cryptographic technique[1] that allows two parties holding sets to compare encrypted versions of these sets in order to compute the intersection. In this scenario, neither party reveals anything to the counterparty except for the elements in the intersection.
Revealing even elements in the intersection, if that means revealing individual votes, breaks ballot secrecy.
You convince yourself the way you do with any elections: you trust the people/system that counts the votes. If you think about it for a second, the requirements of a secret ballot (meaning it's not possible to know who voted who) and the fully verifiability you are asking for are mutually exclusive. You can have either one but not both at the same time.
That being said I think the Estonian voting system does a decent job of being trustworthy. Publishing the source code is a big step to the better as well. As far as I knew the system was written in Java but seems like they have upgraded it in Go. Good job! Probably the best in the world.
All the source code in the world means nothing when it comes to elections. It's the object code, down to firmwares, BMCs/MEs, even microcode that matters. It's hard to establish trust in those things.
I wouldn't say it means nothing, but you are right in that it is not a silver bullet. It is one piece of a chain of custody to build the trust. Having source code is better than not having it. Having verifiable builds is better than not having them. Having trustworthy hardware is better than not having it. You get the gist?
Most likely similarly how you know in regular "paper" elections
In theory, it's much easier to fake a number stored electronically in a computer than a large number of paper ballots.
In practice too. Elections are worth up to trillions of dollars. That means that agencies like state-level actors, and private actors with the necessary resources, will be tempted to mount supply chain and other attacks, and likely will succeed.
Faking paper ballots is totally doable, but you can take various precautions to make that very difficult. For example, you can deliver ballots to polling locations in sequentially-numbered packs and shuffle them at the voter sign-in desk: by shuffling the packs before delivery, by having the elections judges record which packs they got and which numbers went unused, by making them sign ballots prior to placing them on the sign-in table, and so on, you can make it very difficult for elections administration staff to later replace those paper ballots. But you're going to need timely, partial or full hand-count audits in order to make it necessary to replace paper ballots in order to replace results.
Election security is pretty expensive, but compared to the _value_ of elections, it's nothing.
How do you convince yourself of this in a regular election?
In a paper election, you have a chain of people who supervise each other. Depending on where you live, you can volunteer to be part of that and see it for yourself.
In code, you have no insight into what actually happens.
Let's say you encounter a mob society that is convinced that there is a very high risk of election fraud and will apply unnecessary scrutiny to votes, a little rip in the paper or ink not matching standards.
trivia: did you know that a tear in any of the pages of your passport renders it invalid?
Believe it or not there is a chain of people who supervise each other for this e-voting system as well. Anyone can volunteer to be part of it as well.
Logic tests only show that the machines worked correctly as of the logic test. It's easy enough to design them to behave correctly in all cases except actual elections.