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
Any eVoting system adopted by the IACR must at a minimum satisfy the
- 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.
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
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
- 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.
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.