Ballot Stuffing

[sigmavirus24]

Let's posit an election for a large organization in which the list of eligible voters is not available to all of the membership for audit purposes. If we start with the premise that the administrator is looking to control the result of an election. Without complete transparency with the list of voters, an election administrator could add voters and emails that use address extensions to send themselves enough ballots to stuff the box in their favor.

The database can be made public after an election, yes, but any organization unwilling to publish the list of voters and their addresses is likely to be unwilling to publish the databases with that same information.

[DavidMertz]

I believe this is (mostly) correct. The verifiability model for eVote requires that there be a declare size of the voter pool that can be generally verified. I do not think that the actual membership list needs to be disclosed, but its size does, and that size needs to be verifiable.

So posit a malicious Election Administrator for a 1000 person organization. To make any and all fraud by the EA uniformly detectable in principle we would need:

• The size of the voter pool (e.g. 1000) is publicly known, or at least known to the entire membership (and probably to a small number of external auditors).
  • Moreover, that the voting pool is 1000 (not 1100, for example) needs to be believed with informed confidence by eligible voters and auditors.
• The FACT an election notice is being sent will (fairly) reliably reach all of those 1000 eligible voters.
• The complete anonymized election results are published to voters and auditors (or to the public at large) following an election.

Let's look at the attack potentials by a malicious EA.

1. If the EA creates 1100 slots rather than 1000 (with 100 sent to her rather than actual voters), that will be discovered by anyone looking at the final published results.
2. If the EA decides to withhold the actual election notice or ballot from 100 voters to manipulate them herself, those 100 voters who do not receive ballot links will notice and complain of their missing ballots.
3. If the EA votes early on behalf of 100 voters, those voters will notice the problem when they try to vote and are notified they have "already voted."
4. If the EA surreptitiously votes at the last moment on behalf of 100 eligible voters who did not vote then those eligible non-voters will detect that the anonymized ID assigned to them is not marked BLANK but rather with a particular vote. That is, each individual non-voter can only detect this fact for their individual anonymized ID, none have any knowledge of which other votes may be authentic or forged.

[sigmavirus24]

All of that is true, given a set of voters which will all vote or attempt to vote as well as an election administrator who hasn't previously administered votes for the same organization and doesn't know who historically does not vote. Even without creating extra users, given a history of ballots that barely reach or exceed 50% of the electorate, the administrator could extrapolate from history whether or not an individual will vote.

Again, without those prior ballots being available (for others to see who historically votes and who doesn't) no one would notice that someone who hasn't voted in 5 or 7 years is now voting. Nor do I think that's necessarily an indicator of fraud.

[mdipierro]

How does Helios prevent this? Do you have a recommendation for preventing this?

[sigmavirus24]

I wasn't comparing to Helios, but this could be mitigated somewhat with Helios. Helios makes public the list of voters (by alias) and the cryptographic proof of their vote. Provided a stable group of electors and a stable sorting order, the voter aliases could be used to identify fraud, e.g., V1 did not vote this year, or the 9 years prior. Next year V1 does vote, that might be worthy of investigation.

In reality, however, most organizations grow year over year, so the aliases aren't a reliable method.

[mdipierro]

The comparison is important for me because, independently on what the PSF does, if Helios has feature eVote does not have, I want to add that feature. In eVote we do publish the information about who has voted and who has not voted. Is that different?

[DavidMertz]

I'll preface, of course, by noting again that @sigmavirus24 is an honest, intelligent, and careful EA. In the PSF case I would not lack actual confidence if the procedure were "Email your vote to Ian with full return address in the header, then trust him."

That said, we are discussing the threat model of a malicious EA (Mallory), not of Ian. The characterization of a potential fraud is not actually possible without probable detection. The assumption in our model is that Mallory faces a negative consequence for being detected in a fraud which is more significant than her benefit from succeeding in a fraud (or at least highly significant).

All of that is true, given a set of voters which will all vote or attempt to vote as well as an election administrator who hasn't previously administered votes for the same organization and doesn't know who historically does not vote. Even without creating extra users, given a history of ballots that barely reach or exceed 50% of the electorate, the administrator could extrapolate from history whether or not an individual will vote.

The two flaws in this attack by Mallory are:

1. The EA does not have direct access to which anonymous ID corresponds to which voter. Even if Mallory wants to mount a multi-year attack (this attack cannot apply to a single year in isolation), she has to use something outside eVote itself to record the correspondence of voter to ID. Just knowing that 50% didn't vote last year doesn't tell you anything about which 50% that is.
2. Assuming Mallory engages in a multi-year side-channel recording of ID/voter correspondence (e.g. by monitoring the SMTP server used to send out invites), this still does not permit this attack. Knowing that Alice has not voted for the last several years does not establish for Mallory that Alice did not verify her BLANK votes during for those years.

Obviously, one can use a psychological hunch that someone who didn't vote probably didn't verify. But that is only fairly likely. So an EA attack to substitute 1 vote is unlikely to be detected. A substitution of 2 votes is much more likely to be detected. And so on asymptotically as the number of fake votes are substituted. The cumulative probability of at least one detection nears 1.0 pretty fast as the number of fakes increases.