from the previous clerk, the jth re-encrypts it using newly generated random values ¯xji and ¯yij, and outputs:
{(gxji, βxji
R, g
sji), (gyij, βyji
T , g sji)}
Having performed this transformation for each onion pair, he then shuffles them using a secret permutation and forwards (through theWBB) the final output to the next clerk, Cj+1. At the end of the mixing phase, and once all the clerks
have contributed to this, the final output for the registrar onion is (gxt i, βx t i R, gs t i) and (gyt i, βy t i T , gs t
i) for the teller onion, where t is the identity of the last clerk. Tallying. After the election day all the ballot receipts are collected by the election authorities. For each ballot, some calculations (in public) are performed in order to remove each voter’s choice and the resulting values are fed into a resilient re-encryption Mix Net. Following this, a threshold number of mix servers will carry out the decryption operation and finally, the plaintext votes are posted onto the WBB and the election results are announced. The correctness of the re-encryption can be audited using the RPC technique described in [JJR02], and that of the decryption operation can be proved using techniques similar to the Chaum-Pedersen protocol [CP92] (see Subsection 2.8.1).
6.3
Helios Voting System
The Helios voting system [Adi08] is the first Web-based scheme that allows voters to track their ballots, with the results being open for public verification (auditing). It was proposed by Ben Adida in 2008 and since then, further developments have improved the original proposal. For example, its current fourth version, Helios v.4, is under construction and will not support Mix Nets, but its data structures will eventually be able to support them. Due to its ease in setting up an election and verifying the results, the system has been widely used in small-scale elections and more than 100,000 votes have been cast using it. For example, a few student government elections in the United States and in Europe were based on Helios and those organised by the International Association for Cryptographic Research (IACR) use it as well. An analysis of the real-world use of Helios is presented in [dMPQ09].
In this section, an overview of the first version of Helios, as in [Adi08], which utilises a re-encryption Mix Net for anonymising the ballots, is given. For more details about the source code and documentation of all the versions, the reader is referred to https://vote.heliosvoting.org. In general, there are four phases in voting with this system: (i) setting up an election; (ii) ballot casting; (iii) tallying; and (iv) auditing.
Setting up an Election. Anyone can create an election after being registered on the Helios Web-page. Upon creation, Helios generates an El Gamal key pair for this specific election, where only the secret key is kept locally secret. Then, accessing a simple Web-page interface (any modern browser suffices), the cre- ator, who is also called the administrator of the election, can edit as many ballot questions as he wants. Once the ballot questions have been edited, the admin- istrator can invite voters to participate in the elections; each voter receives an email, where her password and additional information regarding the elections are displayed. When everything is ready, all the voters receive an additional email, which contains a hash value of all the election parameters, the URL leading to the election Web-page as well as their usernames and randomly generated passwords; they are now ready to cast their votes.
Ballot Casting. Having opened the received URL for the election, all the election parameters are loaded into the voter’s browser. She can now fill out the ballots by answering the corresponding questions and after double-checking her options, she chooses to seal her ballot, whereby all her selections will be encrypted using the election’s public key. On top of this, a fingerprint (hash value) of the resulting ciphertext appears on her screen and she is now prompted to cast her ballot. After clicking on the “cast” button, a confirmation email is sent to her containing the ciphertext and its hash value.
Anonymisation and Tallying. Similar to all electronic voting schemes, in Helios, aWBB is maintained for publishing all the ballots, which is run by a sin- gle server called the Helios server. Once the election is closed, the administrator can click on the “shuffle” button to trigger the mixing operation. For this pur- pose, the first provable El Gamal re-encryption Mix Net proposed by Sako and Kilian in [SK95] is employed and how it works has been presented in Section 5.4. The Mix Net consists of a number of mix servers which, in turn, re-encrypt and permute the encrypted ballots using fresh random values. All the interme- diate shuffled ciphertexts are posted onto the WBB and each mix server in the sequence reads and operates on them. After all the mix servers have mixed the inputs, the final set of ciphertexts is posted on the WBB. In order to prove the correctness of the mixing and shuffling operation, each mix server produces, when requested, a proof of shuffle. In the Sako-Kilian Mix Net this is performed using interactive zero-knowledge proofs between the verifier (anyone can act as verifier) and the prover (mix servers). However, in Helios, in order to avoid the heavy computational cost when producing these expensive proofs, the Fiat- Shamir heuristic [FS86] is deployed. That is, the challenge values are now com- puted as the hash of the mix and are embedded in the mix message travelling