The Condorcet Internet Voting Service is designed to protect the security and privacy of participants. Some important guarantees it offers include the following:

The remainder of this document describes why these goals are believed to be met.

Election types

CIVS supports both public and private elections. In private elections the election supervisor specifies the list of voters; in public elections there is no list of voters and anyone receiving the appropriate election URL is able to vote. A private election offers much stronger security and authenticity guarantees. In particular, in public elections the IP address of the voter is used to determine whether that voter has already cast a vote. A malicious voter can easily cast multiple votes, which is as good as one can reasonably expect a public election to be. For private elections, voters receive a unique key by e-mail that permits them to vote just once. Further attempts to vote will be rejected. Voters can also be reissued voter keys without giving them the ability to vote again.

CIVS sends various information by e-mail. It assumes that e-mail is a secure, reliable medium. If your e-mail is compromised, this would permit the attacker to impersonate you as a voter or as an election supervisor. If e-mail is unreliable, voter keys could be lost in the mail. However, voter keys can be reissued without creating the possibility that a voter gets an extra vote.


CIVS works by generating several different keys that serve as capabilities. These 64-bit keys are generated using a combination of random noise and secure hashing.

Private election protocol

Election creation

  1. The supervisor requests the creation of a new election, providing the election description and a list of voter e-mail addresses. These addresses are (temporarily) stored on the server. If this temporary storage is undesirable, the voters can be added after the election is started, and their addresses will never be stored in cleartext.
  2. The server generates three fresh nonces to use as the election identifier, as the authorization key for this election, and as the control key. All three are sent to the supervisor in e-mail in a URL.
  3. The election identifier is stored on the server; the server stores the MD5 hash of the control and authorization keys and then forgets the keys.
  4. The supervisor uses the URL in the email to start the election. Providing the URL proves that the supervisor presented a real e-mail address.
  5. The server hashes the provided authorization key and control key to make sure they match the stored hashes.
  6. For each e-mail address, the server performs the steps described below under Adding voters. This results in the creation of a list of valid voter keys, which are mailed to the corresponding e-mail addresses. The server stores the hashes of all of the voter keys.
  7. The cleartext voter e-mail addresses and the corresponding voter keys are now forgotten by the server.


  1. The voter sends the server a ballot b that includes the voter key v.
  2. The server checks whether the hash of the voter key is in the set of valid hashed keys, and whether a ballot has already been cast using the voter key. It reports an error if appropriate.
  3. The server generates a fresh nonce r that serves as the voter receipt.
  4. The server records the ballot indexed by the hash of the voter receipt and the private host key: {r, k}MD5. Thus information on the server doesn't allow the identity of the voter to be determined from the ballot.
  5. The server reports the receipt r to the voter and then forgets r. This enables later checking that the ballot was cast properly, but only with the participation of the voter.

Adding a voter

Given an e-mail address e, the server performs the following steps when a voter is added (either during election creation or later from the election control page):
  1. A voter can only be added by presenting the authorization key a, which is known by the supervisor but not stored on the server. It is, however, available at election creation time. The server stores {a}MD5 to allow checking whether the correct authorization key is presented.
  2. The server computes v = {e, a, k}MD5, which is the voter key. Possession of the key does not permit either direct computation of the e-mail address or (in the absence of the authorization key) a dictionary attack to find the e-mail address. The use of the private host key k prevents the supervisor from forging a voter's key.
  3. The server looks up {v}MD5 in the current set of (hashed) voter keys. If it is already there, it reports an error; otherwise, {v}MD5 is added to the set of voter keys.
  4. It sends v to the e-mail address e, so the voter can later use it to vote.
  5. The server forgets a, e and v.

Public election protocol

A public election works similarly to a private election. The difference is that every voter has the power to add himself as a voter: the URL generated at election creation time includes the authorization key. The voter's IP address is used instead of the voter's e-mail address as the definition of true identity.

Election creation

The election creation protocol for public elections is the same as for private elections except that voters are not added. The supervisor is provided with a voting URL that includes the election id and the authorization key. The supervisor can then distribute this URL through whatever out-of-band mechanism they deem appropriate.


  1. The voter sends the server a ballot b that includes the voter IP address IP and the authorization key.
  2. The server computes x = {IP, a, k}MD5 as the voter key. (Secure in the sense that it does not permit the voter's identity to be determined.)
  3. The server adds the hash of this v to the set of already used voter keys. If it is already in the set, the server reports an error. Note that this check does not defend against malicious voters who vote from multiple IP addresses; such voters are, unfortunately, not uncommon.
  4. The server forgets x and IP.
  5. The server generates a fresh nonce r to use as the voter receipt.
  6. As in private elections, the server records the ballot indexed by the hash of the receipt and the private host key.
  7. The server reports the receipt r to the voter and then forgets r. This enables later checking that the ballot was cast properly, but only with the participation of the voter.

Because the IP address in a public election is hashed using the authorization key, server compromise does not enable the attacker to determine the IP addresses by dictionary attack. Of course, if the attacker has obtained the authorization key for that election (perhaps because the attacker is a voter in the election), a dictionary attack becomes possible.

Data Storage

The following global information is stored on the server. The following per-election information is stored on the server. The election supervisor is sent the following information by email. Each voter possesses the following.


This section describes what attacks might be mounted by attackers with various capabilities and how effectively the system defends against them. We assume here that email and the network are trusted components of the system.