PEV subversion

[danielrichman]

I was wondering if you had considered this / whether this method for subverting the post election verification process would actually work:

• election between candidates A and B; B would win by a small margin but malicious people trusted with access to the voting server would like A to win
• everyone that votes for B is assigned a voting token from a small set; that is, multiple people voting for B are assigned the same token
• extra voting tokens for non-existent voters are created so that (the number of unique tokens) = (the number of people that voted). All of these tokens are used to cast votes for A.
• in the PEV, everyone that voted for B checks that the token they were assigned has indeed been associated with a vote for B, and suspect nothing. They have no reason to reveal their token as they believe their vote to be counted correctly, so won't notice that >=two people have the same token

Other fun scenarios:

• election between candidates A and B; again B would win by a small margin, but A's supporters would like A to win / cause chaos.
• votes for A claim they've all been assigned the same token, when in reality the election was not fixed. The election system has no way of refuting this claim?

An idea?

Voting token could be hash(salt + identity of voter); salt being unique per voter; salt revealed to voter. Identifying voters from the published list requires breaking the hash; a voter can demonstrate that a token is theirs by revealing the salt; assigning two voters the same token requires finding a collision.

[dme26]

On Wed, 17 Jun 2015, Daniel Richman wrote:

I was wondering if you had considered this / whether this method for subverting the post election verification process would actually work:

• election between candidates A and B; B would win by a small margin but malicious people trusted with access to the voting server would like A to win
• everyone that votes for B is assigned a voting token from a small set; that is, multiple people voting for B are assigned the same token
• extra voting tokens for non-existent voters are created so that (the number of unique tokens) = (the number of people that voted). All of these tokens are used to cast votes for A.
• in the PEV, everyone that voted for B checks that the token they were assigned has indeed been associated with a vote for B, and suspect nothing. They have no reason to reveal their token as they believe their vote to be counted correctly, so won't notice that >=two people have the same token

I think the access to the voting server required would be equivalent to having the power to compromise ballots in many other ways too.

In very early incarnations, the lists of tokens were printed out, both sorted by token and by candidate, with a view to this sort of manipulation being detectable.

Other fun scenarios:

• election between candidates A and B; again B would win by a small margin, but A's supporters would like A to win / cause chaos.
• votes for A claim they've all been assigned the same token, when in reality the election was not fixed. The election system has no way of refuting this claim?

The current system would definitely have problems handling this margin's worth of malicious participants, but it's not really been a goal to do so.

An idea?

Voting token could be hash(salt + identity of voter); salt being unique per voter; salt revealed to voter. Identifying voters from the published list requires breaking the hash; a voter can demonstrate that a token is theirs by revealing the salt; assigning two voters the same token requires finding a collision.

Thank you for suggesting this. I am not up to date regarding the actual queries that have reached returning officers, but will seek out some relevant information about that...

Since the salt should not be remembered by the server (to aim to effect decoupling of ballots and voters), while including the voter identity (implicitly) in the token would allow honest voters to demonstrate derivation of their tokens, dishonest voters would be able to claim that their votes were not recorded correctly, and thus could still cause chaos if they wanted to. Possibly I haven't had enough coffee yet to be thinking this through clearly. In any case, I would be interested in exploring systematic means to quantify the threat model.

[danielrichman]

On 17 June 2015 at 12:52, David Eyers notifications@github.com wrote:

On Wed, 17 Jun 2015, Daniel Richman wrote:

I was wondering if you had considered this / whether this method for subverting the post election verification process would actually work:

• election between candidates A and B; B would win by a small margin but malicious people trusted with access to the voting server would like A to win
• everyone that votes for B is assigned a voting token from a small set; that is, multiple people voting for B are assigned the same token
• extra voting tokens for non-existent voters are created so that (the number of unique tokens) = (the number of people that voted). All of these tokens are used to cast votes for A.
• in the PEV, everyone that voted for B checks that the token they were assigned has indeed been associated with a vote for B, and suspect nothing. They have no reason to reveal their token as they believe their vote to be counted correctly, so won't notice that >=two people have the same token

I think the access to the voting server required would be equivalent to having the power to compromise ballots in many other ways too.

Agreed, though these are mainly compromising anonymity? In BOB.php there is the claim

"The catch-all for handling (a) is the post-election verification process"

so I guess at the very least I'm arguing that the documentation there may be misleading.

In very early incarnations, the lists of tokens were printed out, both sorted by token and by candidate, with a view to this sort of manipulation being detectable.

Other fun scenarios:

• election between candidates A and B; again B would win by a small margin, but A's supporters would like A to win / cause chaos.
• votes for A claim they've all been assigned the same token, when in reality the election was not fixed. The election system has no way of refuting this claim?

The current system would definitely have problems handling this margin's worth of malicious participants, but it's not really been a goal to do so.

To a certain extent, a small malicious group could still cause trouble by claiming they've been given the same token as someone else, regardless of the size of the margin? At the very least, cast doubt on the vote.

An idea?

Voting token could be hash(salt + identity of voter); salt being unique per voter; salt revealed to voter. Identifying voters from the published list requires breaking the hash; a voter can demonstrate that a token is theirs by revealing the salt; assigning two voters the same token requires finding a collision.

Thank you for suggesting this. I am not up to date regarding the actual queries that have reached returning officers, but will seek out some relevant information about that...

I'm not 100% sure what you meant here, but for avoidance of doubt I'm not the RO of any election nor have chatted to a RO about this; I merely was interested in how it worked, which lead to the idea in this issue.

Since the salt should not be remembered by the server (to aim to effect decoupling of ballots and voters), while including the voter identity (implicitly) in the token would allow honest voters to demonstrate derivation of their tokens, dishonest voters would be able to claim that their votes were not recorded correctly, and thus could still cause chaos if they wanted to. Possibly I haven't had enough coffee yet to be thinking this through clearly. In any case, I would be interested in exploring systematic means to quantify the threat model.

I don't think anything can stop a voter claiming their vote was recorded incorrectly. They could just deliberately vote "incorrectly", and lie and say they didn't actually do that.

I think that a salt+hash based method would prevent dishonest voters claiming that two voters had been assigned the same voting token. They would both have to reveal their salts, and then the public can calculate their hashes/tokens, which will be different (under the assumption that they can't find a collision). I don't think this requires the server to remember the salts, and indeed I do not think it should.

—

Reply to this email directly or view it on GitHub https://github.com/cusu/bob/issues/1#issuecomment-112768932.

[dme26]

On Wed, 17 Jun 2015, Daniel Richman wrote:

I think the access to the voting server required would be equivalent to having the power to compromise ballots in many other ways too.

Agreed, though these are mainly compromising anonymity? In BOB.php there is the claim

"The catch-all for handling (a) is the post-election verification process"

so I guess at the very least I'm arguing that the documentation there may be misleading.

Ahh, got it. So more like "The attempted catch-all for handling..."? ;-)

The current system would definitely have problems handling this margin's worth of malicious participants, but it's not really been a goal to do so.

To a certain extent, a small malicious group could still cause trouble by claiming they've been given the same token as someone else, regardless of the size of the margin? At the very least, cast doubt on the vote.

The hope was that the legitimate counting margins would be larger than the doubts being cast.

Thank you for suggesting this. I am not up to date regarding the actual queries that have reached returning officers, but will seek out some relevant information about that...

I'm not 100% sure what you meant here, but for avoidance of doubt I'm not the RO of any election nor have chatted to a RO about this; I merely was interested in how it worked, which lead to the idea in this issue.

Yes, that all good, and understood.

I don't think anything can stop a voter claiming their vote was recorded incorrectly. They could just deliberately vote "incorrectly", and lie and say they didn't actually do that.

Agreed.

I think that a salt+hash based method would prevent dishonest voters claiming that two voters had been assigned the same voting token.

I agree, although I suspect that everything rapidly gets messy, as the malicious user will be compromising the anonymity (maybe only to the RO, but still) of the other voter through needing to have them demonstrate that they own their token. This is the type of thing I'd be interested to hear more about from ROs who have had to handle problem cases.

They would both have to reveal their salts, and then the public can calculate their hashes/tokens, which will be different (under the assumption that they can't find a collision).

I don't think this requires the server to remember the salts, and indeed I do not think it should.

Yep, agreed both that the server doesn't and shouldn't need to store the salts. The utility / threat trade off is something I'd be keen to see more systematically explored, as mentioned before. I haven't sought out established methodologies for doing so yet, though.