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 [email protected] 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
#1 (comment).

[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.