E-Voting Systems for the IACR

Requirements and Evaluation Criteria

The IACR board is debating a proposal to replace the current mail-based system that is used by the IACR for its internal elections with a cryptographic e-voting system. In connection with this debate, the IACR board heard several presentations in August 2008. The board also established a committee to evaluate these presentations, consisting of Yvo Desmedt, Stuart Haber, Shai Halevi, James Hughes, Antoine Joux, and Jean-Jacques Quisquater . The committee was asked to produce a summary recommendation for the board, preferably of at most two systems that can be run in a trial election.

Aided by Josh Benaloh, Ron Rivest, David Wagner, and Moti Yung, the committee came up with the following list of requirements and evaluation criteria. We are seeking feedback on these requirements and evaluation criteria. Feedback can be provided either by email to any member of the committee above, or by posting on this Wiki page

Requirements

Any eVoting system adopted by the IACR must at a minimum satisfy the following requirements.

A. Usability

The system must exist, i.e. it must have an implementation. Moreover, the system software must be open-source.
The system must be user-friendly, at least from the voters' point of view.
The system must be easy for IACR volunteers to maintain and manage. (For example, we may require that the developers commit to provide support in the form of bug-fixes and maintenance help for the first few years of operation.)

B. Security and Robustness

Eligible voters (i.e. IACR members) must be able to vote exactly once. The system must be able to verify that voters are members of the IACR.
Individual votes must remain secret. The system must prevent attackers from learning how individual members voted.
The system must have universal verifiability of the integrity of the election outcomes. Namely, the system must allow open audit, where everyone can verify that only valid votes were counted and the tally is accurate, and every voter can verify that his/her vote was counted.
The system must be accessible, available, and reliable.

Additional Considerations

In addition to the above requirements, we list below some properties that are not a must-have, but will still be taken into account when evaluating the systems.

Offering some measure of resistance to denial-of-service attacks, and making it possible to fix system outages in a matter or hours or days. For example, DoS attacks on clients can be addressed by allowing members to vote from any machine, even if their machine breaks in mid-vote. DoS on the server may be addressed by distributing the server and/or by making it possible to manually re-locate the server (or even switch to a different communication medium).
Offering some measures of resistance to vote modifications by viruses and malware (even on the client).
Minimizing the level of trust that is required of any entity in the system. (For example, servers' secrets could be shared with a 3-out-of-5 threshold, corresponding to the three people required for ballot-counting by the current version of the IACR bylaws .)
Offering some measure of receipt-freeness (or even coercion-freeness). For example, the system can allow voters to cast "fake votes" that would be silently discarded in the tallying process. (This ensures that an attacker must be able to reliably monitor the member's client machine over time in order to obtain a receipt that proves how that member voted.)
Defense against attacks based on correlation between votes. For example, even knowing how a member voted for directors, it should not be possible to deduce who he/she voted for president. This can be achieved using split races.

Non Requirements

It is important to stress that elections in a small organization such as the IACR are very different from general elections in the public sector. Indeed, several important requirements from public-sector elections are not needed (or not so important) for the IACR. Below we list some of these "non-requirements".

Full resistance to coercion and vote-selling . In public-sector elections it is important that attackers are prevented from monitoring the voters' systems (even if the voters themselves want to allow such monitoring), to prevent cases of wide scale coercion or vote selling. This aspect is much less important for the IACR, and the weaker Bullet 11 from above seems quite sufficient in our setting.
Full robustness . In public-sector elections, it should be all but impossible to prevent voting from concluding on election day. For the IACR, on the other hand, a transient failure may be tolerable, even if it means that the voting deadline is extended by a week or two. Hence, the weaker requirement 8 from above seems sufficient in our setting.
Paper trail . For public-sector elections it is crucial to maintain some paper trail that can be examined if the need arises. (See for example this statement .) We believe that such paper trail is not needed for the IACR.

We stress again that even if the IACR adopts an electronic voting system, we do not expect this system to be suitable for public-sector elections. In fact, any system that the IACR may use will be a vote-from-home system, whereas no vote-from-home system can be safely used in public-sector elections.