<p>(Summarizing the discussion in the comments)</p>

<p>A mechanism to defend against bribes/coercion:</p>

<p>The simplest variant is, make the voter enter a password in order to vote, but do <em>not</em> provide an indication whether the password was correct. That is, if the voter enters a correct password and votes, the vote is registered, whereas if the voters enters an incorrect password and votes, the vote is ignored but the result looks the same on the client side. This has the drawback that, if the voter enters a wrong password by mistake, their vote will not count and they won't even know this.</p>

<p>The drawback can be somewhat ameliorated by allowing tolerance to small edit distance. A more complex solution is, provide each voter with one true password and a way to randomly generate exponentially many (but still sparse w.r.t. edit distance) false passwords, s.t. even an attacker who knows the generating algorithm cannot tell whether a given string was generated by it (alternatively, just sample the true password from the same distribution). </p>

CC BY-SA 4.0
2018-09-12T21:17:07.403Z
I think this underestimates the challenges.  A major challenge is that we  want both verifiability and coercion-resistance.  This answer ignores verifiability.  Most methods for verifiability introduce problems for coercion-resistance, and just using a password doesn't make those go away.  Something more sophisticated is needed.  There's a reason why there's an entire line of work in the literature on this subject; it's not that researchers didn't think of this idea.
D.W.
CC BY-SA 4.0
2018-09-12T22:05:52.340Z
I did not claim the researchers didn't think of this idea! I just tried to answer the question to the best of my ability, and the OP said they find this answer valuable. How do methods for verifiability introduce problems for coercion resistance? That sounds interesting.
Vanessa
CC BY-SA 4.0
2018-09-13T00:55:34.520Z
The methods for verifiability involve ways for voters to verify that their vote was included in the final tally. That's exactly what you don't want if you want to prevent the coercer from knowing whether the vote  the voter entered will count or not.  Thus, your proposal that "the result looks the same" to the voter is inconsistent with the natural approaches to verifiability.  Resolving that tension requires some non-trivial, sophisticated methods.
D.W.
CC BY-SA 4.0
2018-09-13T23:31:31.193Z
@D.W. What are those sophisticated methods?
Demi
CC BY-SA 4.0
2018-09-14T00:36:14.980Z
@Demi, I'd refer you to [my answer](https://cstheory.stackexchange.com/a/41531/5038) where I give some pointers to where you can start finding some of the literature on that topic.
D.W.
CC BY-SA 4.0
2018-09-29T03:32:14.977Z
Regarding verifiability: after the user inputs their vote and password, the system displays one of two word. Only the user knows whether which word indicates that the vote went through correctly, and which word indicates that the password was input incorrectly. Do you see any flaws in this?
Elle Najt
CC BY-SA 4.0
2018-09-12T19:44:23.523Z
2018-09-12T19:44:23.523Z
Vanessa
<p>This question is probably too broad to be answerable here, because the answer depends on what kinds of security requirements you have, what the threat model is, and what assumptions we're willing to make -- there are many different versions of those.  In other words, the "secure voting" problem is not one problem, but a broad class of problems.  I suggest doing a literature search, reading some of the classic papers, then see if you have a more specific question.  You could start with papers published at EVT and WOTE use them to seed your literature search.</p>

<p>If you're specifically interested in coercion, I suggest looking at Juels, Catalano, and Jakobson (WPES 2005) and Civitas (IEEE S&amp;P 2008).  Those are two important early papers.  Also, by doing a search on papers that cite them, you'll be able to turn up a lot of more recent work on coercion.</p>

<p>All of these schemes have something in common; they do require some kind of trusted channel to the voter or some situation where the voter does register in person in a supervised environment.  They might not require supervision during the time of voting; that can be pushed to a setup phase.</p>

<p>Also, the solutions may depend on whether you are willing to assume that voters have a personal device (e.g., smartphone) and whether voters are willing to trust it.  Obviously the problem gets easier if you answer that in the affirmative.</p>

CC BY-SA 4.0
2018-09-11T20:47:09.500Z
Thank you for the detailed answer. I'm not a cryptographer, so I wouldn't even know to ask the right questions. I understand from your response that the problem of securely voting from home is far from being solved, even theoretically.
Aryeh
CC BY-SA 4.0
2018-09-11T20:41:08.590Z
2018-09-11T20:41:08.590Z
D.W.
<p>Is there a cryptographic protocol which, at least in theory (and under standard cryptographic assumptions) enables people to securely vote from their homes? I could see how the various problems might be addressed (such as: preventing people from voting twice, producing proof that the vote was registered while revealing no information about who the vote was for) except for one: <em>preventing coercion</em> (that is making sure that the voter isn't being bribed or otherwise forced to vote a certain way). This seems to be impossible, in principle, without the voter being physically present at a voting center with overseers watching, but maybe I'm not sufficiently thinking outside the box?..</p>

CC BY-SA 4.0
2018-09-11T20:29:36.737Z
Maybe a computer embedded in the brain could solve the coercion problem.
Bjørn Kjos-Hanssen
CC BY-SA 4.0
2018-09-12T10:44:25.020Z
What if, the voter enters a password, and the vote is only registered if the password is correct, but there is no indication whether the password was correct. This has the drawback that some people will enter the wrong password by mistake and won't realize that, but maybe you can improve on that somehow.
Vanessa
CC BY-SA 4.0
2018-09-12T12:22:49.030Z
@Squark Brilliant! That's exactly the sort of thing I *should have* thought of. Deniable passwords. The voter is issued many "fake" passwords and 1 real one. When logging in under duress, he can enter a fake password and get a fake confirmation. If you make this into an answer, I'll accept.
Aryeh
CC BY-SA 4.0
2018-09-12T12:34:48.843Z
Yes, I thought about fake passwords. The problem with that is, if every voter gets 1 real password and 4 fake passwords (say) then the attacker can demand to see the voter voting with 5 different passwords. Now, you can say that once a fake password is entered, any following vote is not registered, even if using the real password. This protects from forcing/bribing voting for a given candidate, but doesn't protect from forcing/bribing of *not* voting at all.
Vanessa
CC BY-SA 4.0
2018-09-12T12:41:41.170Z
Users can get an infinite sequence of fake passwords. Like: anything accepted by THIS (private) automaton is a fake password, while here is the 1 real one.
Aryeh
CC BY-SA 4.0
2018-09-12T13:07:50.237Z
Yes. You could give the voters a way of generating exponentially many fake passwords (for example by entering their name and date of birth into some application) s.t. it is computationally infeasible to say whether a given password was generated in this way. This may not help if someone barges into your house and puts a gun to your head, unless you made the effort to prepare fake passwords in advance, but it certainly helps against all scenarios where the voter can prepare in private.
Vanessa
CC BY-SA 4.0
2018-09-12T13:09:28.733Z
Look, even with in-person voting at the polls, someone could force you to wear a hidden camera that records what you do. I think infinitely/exponentially many fake passwords is of comparable security. Well done! [Feel free to turn into an answer -- I'll accept and I suspect it'll get upvotes.]
Aryeh
CC BY-SA 4.0
2018-09-13T14:37:40.107Z
It doesn't make a lot of sense to me to ask "what is the state of the art" in a research area and then quickly accept an original idea. Nothing against Squark's idea, which is great, but why not wait for some answers with references to the literature?
usul
CC BY-SA 4.0
2018-09-13T16:01:40.190Z
Hmm, you may have a point.  When such an answer comes along I’ll reconsider.
Aryeh
CC BY-SA 4.0
2019-09-11T07:16:46.733Z
Look at [Helios](https://heliosvoting.org/docs) used by IACR
kelalaka
<cr.crypto-security>
What is the state of the art in online voting?
Aryeh
# What is the state of the art in online voting?

(Asked by: username_0 on 2018-09-11)

Is there a cryptographic protocol which, at least in theory (and under standard cryptographic assumptions) enables people to securely vote from their homes? I could see how the various problems might be addressed (such as: preventing people from voting twice, producing proof that the vote was registered while revealing no information about who the vote was for) except for one: *preventing coercion* (that is making sure that the voter isn't being bribed or otherwise forced to vote a certain way). This seems to be impossible, in principle, without the voter being physically present at a voting center with overseers watching, but maybe I'm not sufficiently thinking outside the box?..

**Tags:** cr.crypto-security
> **Comments:**
> **username_1**: Maybe a computer embedded in the brain could solve the coercion problem.  
> **username_2**: What if, the voter enters a password, and the vote is only registered if the password is correct, but there is no indication whether the password was correct. This has the drawback that some people will enter the wrong password by mistake and won't realize that, but maybe you can improve on that somehow.  
> **username_0**: @Squark Brilliant! That's exactly the sort of thing I *should have* thought of. Deniable passwords. The voter is issued many "fake" passwords and 1 real one. When logging in under duress, he can enter a fake password and get a fake confirmation. If you make this into an answer, I'll accept.  
> **username_2**: Yes, I thought about fake passwords. The problem with that is, if every voter gets 1 real password and 4 fake passwords (say) then the attacker can demand to see the voter voting with 5 different passwords. Now, you can say that once a fake password is entered, any following vote is not registered, even if using the real password. This protects from forcing/bribing voting for a given candidate, but doesn't protect from forcing/bribing of *not* voting at all.  
> **username_0**: Users can get an infinite sequence of fake passwords. Like: anything accepted by THIS (private) automaton is a fake password, while here is the 1 real one.  
> **username_2**: Yes. You could give the voters a way of generating exponentially many fake passwords (for example by entering their name and date of birth into some application) s.t. it is computationally infeasible to say whether a given password was generated in this way. This may not help if someone barges into your house and puts a gun to your head, unless you made the effort to prepare fake passwords in advance, but it certainly helps against all scenarios where the voter can prepare in private.  
> **username_0**: Look, even with in-person voting at the polls, someone could force you to wear a hidden camera that records what you do. I think infinitely/exponentially many fake passwords is of comparable security. Well done! [Feel free to turn into an answer -- I'll accept and I suspect it'll get upvotes.]  
> **username_3**: It doesn't make a lot of sense to me to ask "what is the state of the art" in a research area and then quickly accept an original idea. Nothing against Squark's idea, which is great, but why not wait for some answers with references to the literature?  
> **username_0**: Hmm, you may have a point.  When such an answer comes along I’ll reconsider.  
> **username_4**: Look at [Helios](https://heliosvoting.org/docs) used by IACR  

---

## 2 answers

### Answer by username_2 on 2018-09-12. Score: 3 | Accepted answer

(Summarizing the discussion in the comments)

A mechanism to defend against bribes/coercion:

The simplest variant is, make the voter enter a password in order to vote, but do *not* provide an indication whether the password was correct. That is, if the voter enters a correct password and votes, the vote is registered, whereas if the voters enters an incorrect password and votes, the vote is ignored but the result looks the same on the client side. This has the drawback that, if the voter enters a wrong password by mistake, their vote will not count and they won't even know this.

The drawback can be somewhat ameliorated by allowing tolerance to small edit distance. A more complex solution is, provide each voter with one true password and a way to randomly generate exponentially many (but still sparse w.r.t. edit distance) false passwords, s.t. even an attacker who knows the generating algorithm cannot tell whether a given string was generated by it (alternatively, just sample the true password from the same distribution).

> **Comments:**
> **username_5**: I think this underestimates the challenges.  A major challenge is that we  want both verifiability and coercion-resistance.  This answer ignores verifiability.  Most methods for verifiability introduce problems for coercion-resistance, and just using a password doesn't make those go away.  Something more sophisticated is needed.  There's a reason why there's an entire line of work in the literature on this subject; it's not that researchers didn't think of this idea.  
> **username_2**: I did not claim the researchers didn't think of this idea! I just tried to answer the question to the best of my ability, and the OP said they find this answer valuable. How do methods for verifiability introduce problems for coercion resistance? That sounds interesting.  
> **username_5**: The methods for verifiability involve ways for voters to verify that their vote was included in the final tally. That's exactly what you don't want if you want to prevent the coercer from knowing whether the vote  the voter entered will count or not.  Thus, your proposal that "the result looks the same" to the voter is inconsistent with the natural approaches to verifiability.  Resolving that tension requires some non-trivial, sophisticated methods.  
> **username_6**: @D.W. What are those sophisticated methods?  
> **username_5**: @Demi, I'd refer you to [my answer](https://cstheory.stackexchange.com/a/41531/5038) where I give some pointers to where you can start finding some of the literature on that topic.  
> **username_7**: Regarding verifiability: after the user inputs their vote and password, the system displays one of two word. Only the user knows whether which word indicates that the vote went through correctly, and which word indicates that the password was input incorrectly. Do you see any flaws in this?  

---

### Answer by username_5 on 2018-09-11. Score: 6

This question is probably too broad to be answerable here, because the answer depends on what kinds of security requirements you have, what the threat model is, and what assumptions we're willing to make -- there are many different versions of those. In other words, the "secure voting" problem is not one problem, but a broad class of problems. I suggest doing a literature search, reading some of the classic papers, then see if you have a more specific question. You could start with papers published at EVT and WOTE use them to seed your literature search.

If you're specifically interested in coercion, I suggest looking at Juels, Catalano, and Jakobson (WPES 2005) and Civitas (IEEE S&P 2008). Those are two important early papers. Also, by doing a search on papers that cite them, you'll be able to turn up a lot of more recent work on coercion.

All of these schemes have something in common; they do require some kind of trusted channel to the voter or some situation where the voter does register in person in a supervised environment. They might not require supervision during the time of voting; that can be pushed to a setup phase.

Also, the solutions may depend on whether you are willing to assume that voters have a personal device (e.g., smartphone) and whether voters are willing to trust it. Obviously the problem gets easier if you answer that in the affirmative.

> **Comments:**
> **username_0**: Thank you for the detailed answer. I'm not a cryptographer, so I wouldn't even know to ask the right questions. I understand from your response that the problem of securely voting from home is far from being solved, even theoretically.  

---

