On the Feasibility of E2E Verifiable Online Voting – A Case Study From Durga Puja Trial

. India is the largest democracy by population and has one of the largest deployments of e-voting in the world for national elections. However, the e-voting machines used in India are not end-to-end (E2E) verifiable. The inability to verify the tallying integrity of an election by the public leaves the outcome open to disputes. E2E verifiable e-voting systems are commonly regarded as the most promising solution to address this problem, but they had not been implemented or trialed in India. It was unclear whether such systems would be usable and practical to the Indian people. Previous works such as Helios require a set of tallying authorities (TAs) to perform the decryption and tallying operations, but finding and managing TAs can prove difficult. This paper presents a TA-free E2E verifiable online voting system based on the DRE-ip protocol. In collaboration with the local authority of New Town, Kolkata, India, we conducted an online voting trial as part of the 2022 Durga Puja festival celebration, during which residents of New Town were invited to use mobile phones to vote for their favourite pujas (festival decorations) in an E2E verifiable manner. 543 participants attended the Durga Puja trial and 95 of them provided feedback by filling in an anonymous survey after voting. Based on the voter feedback, participants generally found the system easy to use. This was the first time that an E2E online voting system had been built and tested in India, suggesting its feasibility for non-statutory voting scenarios.


Introduction
India is the largest democracy in the world by population, and one of the earliest adopters of electronic voting (e-voting) for national elections.E-voting machines, known as Electronic Voting Machines (EVMs), were first used in elections in India in 1998, and today, they have replaced paper ballots in all state and general elections, and almost all local elections.Twenty years of deployment of e-voting in legally binding elections in India has built up an asset of experience and provided the world with useful lessons.
One of the most important lessons concerns the security of e-voting.With the existing design of EVM, voters must trust that the machine functions correctly and honestly, but they cannot independently verify if that is the case [1].In a civic poll in Uttar Pradesh in November 2017, some voters discovered that an EVM always recorded votes for a fixed candidate, irrespective of the button that was being pressed [2].Officials attributed this to a ''malfunction'' and replaced the affected machines.Similar malfunctions had been reported before, e.g., during elections in Maharashtra in July 2017 [3].These instances of EVM malfunction inevitably raise the question: how can it be assured that a similar malfunction does not happen in an election in an undetectable way?
One promising solution, widely supported by the research community, is to make an e-voting system end-to-end (E2E) verifiable [4].Here, the E2E verifiability refers to voters being able to verify their votes are cast-as-intended, recorded-as-cast and tallied-as-recorded.The malfunction cases reported in Uttar Pradesh and Maharashtra show an example of not fulfilling the cast-as-intended requirement.Yet, despite the advancement of e-voting research, E2E verifiable voting systems had not been implemented or trialled in India.It was unclear whether such systems would be usable and practical for Indian people.
We reached out to the Election Commission of India (ECI) with a proposal to validate the feasibility of E2E verifiable e-voting in the country.Subsequent meetings with the IT secretary of the West Bengal state were arranged to discuss suitable trial opportunities.However, instead of doing a trial as part of a statutory election, it was suggested that the trial be conducted for an informal non-statutory election to build a case study first.One opportunity that arose from the discussions https://doi.org/10.1016/j.jisa.2024.103719was to conduct an online voting trial as part of the annual Durga Puja festival celebration at New Town, Kolkata.New Town is a modern satellite city of Kolkata in the West Bengal state.Durga Puja is one of the most important festivals in India, especially in Kolkata.From 2019, the research team had several meetings with New Town Kolkata Development Authority (NKDA), the local governing body of New Town, to gather the design requirements for an E2E verifiable online voting system to be used in the trial.In 2022, in-person celebrations for Durga Puja were revived in many parts of India including New Town after the COVID-19 pandemic.For the first time, residents of New Town were provided with an opportunity to vote for their favorite pujas (festival decorations) online in an E2E-verifiable manner.
In this paper, we present an E2E verifiable online voting system based on Shahandashti and Hao's DRE-ip protocol [5] (with adaptations).Compared with other E2E voting schemes, the DRE-ip protocol has a distinctive feature that it is free from any tallying authorities (TAs).As we will show, the removal of TAs significantly simplifies election management.The system development started from scratch and took about a year, comprising around 25,000 lines of code.Voters cast votes using mobile phones or computers through a public web interface. 1The backend code including all cryptographic implementations is available as open-source. 2In collaboration with NKDA, we successfully conducted an online voting trial among the New Town residents as part of the Durga Puja festival celebration.To the best of our knowledge, this is the first time that an E2E online voting system has been implemented and trialled in India.We explain the details of the voting system design (Section 3), the implementation (Section 4), the Durga Puja trial (Section 5) and the survey results (Section 6).This trial serves to provide a case study that demonstrates the feasibility of E2E online voting, in place of vanilla (or black-box) online voting, for an informal non-statutory election.We leave the study of the suitability of E2E online voting, as an alternative choice of postal voting, for statutory elections to future research.

Background
In general, there are two types of voting applications: local and remote voting.The former is conducted locally at polling stations in a supervised environment, while the latter is conducted remotely in an unsupervised environment.In either case, voters may use paper ballots or electronic means.In this section, we will focus primarily on remote voting.Table 1 compares several remote voting systems in terms of the E2E verifiability requirements.
Postal voting (also called mail-in voting) is a popular form of remote voting legally permitted in many democratic countries.In the UK, about 20% of the electorate choose postal voting in general elections.In other countries, the proportion of the electorate which choose postal voting has been steadily increasing [6].In postal voting, a voter is able to verify that a vote is cast as intended (since they manually write the candidate choice).However, a voter cannot verify how a paper ballot will be recorded and tallied after it is posted.
Internet voting allows voters to vote online through a web browser.A vanilla version of Internet voting simply asks voters to choose candidates on a web page and tallies the submitted votes on the server.
Voters are required to completely trust the system, but their electronic ballots, as well as the tally, may be maliciously changed without their awareness.Such a vanilla system is also called a ''black-box'' e-voting system [7].Examples include those used for 2022 IEEE Annual Election and the 2022 Tory party leadership election.In these elections, voters had no means to independently verify the tallying integrity.
A prominent online voting system that has been used for national elections is Estonian Internet voting [4].In 2005, Estonia became the first country that allowed Internet voting for national elections, and today about 50% of the ballots are cast online.As compared with a vanilla system, the Estonian online voting system is partially verifiable -in particular, a voter can verify that their vote is cast-as-intended (by forcing the voting device to reveal the randomness used in the encryption of a ballot), but not that it is correctly recorded-as-cast and tallied-as-recorded [4].Voters must trust the server for the tallying integrity.If the server is compromised, the attacker can freely modify the tally without being detected, as demonstrated by Springall et al. [8].
E2E verifiable e-voting systems are commonly regarded as the most promising solution to protect the tallying integrity since by design they must satisfy all three verifiability requirements (see Table 1).Wellknown E2E voting systems include Chaum's voter verifiable scheme, Prêt à Voter, Scantegrity, Helios and STAR-vote [4].All of these schemes require a set of Tallying Authorities (TAs) to perform decryption and tallying operations.However, finding and managing such TAs has proved difficult [9].This motivates designing E2E voting systems that are TA-free, e.g., DRE-i [7] and DRE-ip [5].DRE-i chooses to precompute encrypted ballots but the pre-computed ballots need to be securely stored.A compromise of the storage will reveal the secrecy of all ballots.By comparison, DRE-ip encrypts ballots in real-time, and can provide a stronger guarantee of ballot secrecy: when the system is completely compromised, while the tallying integrity remains intact due to E2E verifiability, only the partial tally at the time of compromise is revealed, representing minimum information leakage [5].While DRE-i and DRE-ip are designed to only support the simple plurality voting scheme, they can be extended to support more complex rankedchoice voting schemes such as Borda count [10], Condorcet [11] and Instant Run-off [12] without requiring TAs.In this work, we are only concerned with plurality voting.

System design
This section explains the requirements for the Durga Puja online voting system, the architectural design and the authentication mechanism.

Requirements
Based on the meetings with NKDA, the following requirements were specified.
1. E2E verifiability -The online voting system shall be E2E verifiable (which is the main goal of the trial).2. Admin automation -The election management should be automated without TAs (there are no resources from NKDA to serve as any TA).3. Mobile phone friendliness -A voter should be able to vote from a mobile phone as long as it has Internet access.They can also vote from computers.
4. Option of verification -The option to verify votes should be available to voters, but not imposed on them as mandatory.This is for usability reasons.

No registration -No registration is required; anyone with a valid
India mobile number can participate in this trial.This is to facilitate participation.6. Support for two categories -There are two communities in New Town called housing and block, which correspond to two categories of voting.A voter needs to choose one of the two categories and vote within the chosen category.

Satisfying (1-4).
To achieve E2E verifiability we chose DRE-ip [5], which does not require any TAs.The removal of TAs significantly simplifies election management.After the election parameters (i.e., voting questions, candidates, start/end time) are specified, the remaining management process is automated in a publicly verifiable manner.As soon as the election ends, the tally is instantly available, together with publicly available audit data to enable anyone to verify the tallying integrity.As the cryptographic operations are performed on the server according to DRE-ip, a voter can use a plain browser on a resourceconstrained device such as a mobile phone to vote.In DRE-ip, the voter verification step has been naturally integrated into the voting process as a 'cancel/confirm' step, which gives every voter an option to verify votes.
Satisfying (5).To facilitate remote participation in this trial, we adopt a single-factor (token) authentication scheme.The voter provides a mobile phone number, and proves the ownership of that number by entering a 6-digit One-Time Passcode (OTP) that the system sends to that number through SMS.The system formats the provided number according to the international phone number formatting standard (E.164) and accepts only valid India numbers (international code +91).To preserve privacy, we do not store any phone number in plaintext on our system.Instead, we store an HMAC tag  =   (''phone number'') where  is a HMAC key (stored in the system together with the private signing key used to sign data for publication on the bulletin board).This allows us to check if the phone number has been used before without storing it in plaintext.To address the threat of a bot guessing OTP, we add reCAPTCHA (v2) as part of the authentication process.If a voter has more than one mobile phone number, they can cast a vote using each different mobile number.This is considered acceptable in the context of this trial (there is no award for the winners, except an honourable mention of their names on the NKDA website).In a real election, proper registration is required and then ''one-man-onevote'' can be enforced by checking the phone number against a list of registered numbers.Furthermore, instead of using SMS (which is being replaced by a token-based authenticator in many applications), alternative schemes based on multiple factors (e.g., password + authenticator) can be used to strengthen authentication in real elections.
Satisfying (6).To fulfill Requirement 6 and to make the system flexible and generally useful, we define groups of voters, each of which can vote on a subset of questions.Different groups may be mutually exclusive or overlap.In the most common case, the electorate contains only one group.The system is designed to support any number of groups.When we create an election, we can assign specific voting questions to specific groups.For the New Town Durga Puja trial, we define two mutually exclusive groups (block/housing).A voter must choose to belong to one of the two groups, and once the choice is confirmed, it cannot be changed.Voters in each group elect the best puja within their respective group.

Architecture
The voting system can be subdivided into two primary components: an election server, and a web voting interface.The server implements cryptographic functions of DRE-ip using Rust, in conjunction with MongoDB for backend storage.The use of Rust has the advantages of eliminating classes of bugs (e.g., memory safety bugs) at compiletime, and supporting concurrent requests efficiently.The front-end interface adopts the open-source JavaScript framework Vue.js to provide a single-page web application.Each page is considered as a view, composed of different components.Each component is split into three sections: template (HTML), styling (CSS) and behavior (JavaScript).This allows for designing web pages in a more organized manner.Among numerous CSS frameworks available, we chose Tailwind, which is lightweight, offers the freedom to create a unique user interface, and is compatible with mobile devices.The voting interface interacts with the back-end of the system by issuing requests for resources (read/write) or voter actions to the election server.All the requests are run over HTTPS.
To allow portable deployment of the system on any platform, we use Docker, a platform-independent service for application deployment.The use of Docker separates applications into containers that can interact with each other, and ensures that services can run identically regardless of the host operating system.Dependencies are automatically managed, and environments are encapsulated.We deploy the e-voting system as a multi-container Docker application on a Virtual Private Server (VPS) in a public cloud.

Authentication
The voting system distinguishes three types of users: (1) a coordinator, who has the administrative right to create elections; (2) a voter, who has the right to cast one ballot; and (3) a public member, who is free to view a public bulletin board page without any authentication.In our implementation, a coordinator is authenticated by a username and password.A voter is authenticated based on proving the ownership of a mobile phone number, i.e., providing an OTP sent to that mobile phone.A public member does not need authentication.

Durga Puja online voting system
The Durga Puja online voting system is based on implementing DRE-ip with adaptations according to the requirements in Section 3.1.The system implementation consists of three phases: setup, voting and result, as we detail below.

Setup phase
The original DRE-ip protocol [5] is specified in a DSA-like multiplicative group for a single-candidate election.But in our system, we choose to implement it using an additive group over an elliptic curve for better efficiency.We extend the single-candidate specification by running it in parallel for multiple candidates with an additional zero-knowledge proof (based on Chaum and Pedersen [13]) to enforce that only one candidate may be selected from a list.Let (  ) be an elliptic curve defined over a finite field   where  is a large prime.The system works in the subgroup over (  ) of prime order .We adopt the NIST P-256 elliptic curve, which is well supported in Rust.
(Alternative curves such as Curve25519 can also be used.)The setup of an election involves deriving two generators: namely,  1 and  2 , whose discrete logarithm relation is unknown to anyone.We define the standard generator from NIST P-256 as  1 and obtain  2 by using a hash_to_curve algorithm3 with election-specific data (e.g., election name, start/end time, candidates etc.) as the input to the hash function.On the P-256 curve (where the co-factor is 1), any non-identity point can serve as a generator.Hence, computing  2 is straightforward.
The setup phase also involves generating a pair of digital signing keys using ECDSA for each election.The ECDSA keys are used to ensure the authenticity of the data published on the bulletin board.
We choose the same NIST P-256 curve for implementing ECDSA.The public key is published on the public bulletin board before the election.During an election, all the audit data published on the bulletin board for voter verification is digitally signed by the corresponding ECDSA private key for proving the authenticity of the published data.Once the coordinator defines the parameters for an election, including the election title, start/end time, questions and candidates, the subsequent management of an election is automated.The voting phase will start and end automatically, with publicly verifiable audit data published on the bulletin board to allow every voter to verify the tallying integrity, as we explain in the next phase.

Voting phase
A voter must first pass the authentication as described in Section 3.They then need to choose whether they vote in the ''block'' or ''housing'' group based on the requirements in Section 3.1.For each group, voters are presented with the same voting question (defined by NKDA): ''Best Puja under citizen choice''.They are allowed to choose only one candidate from the given list in the respective group.
The original DRE-ip protocol is specified for a single-candidate election, in which each voter casts one vote   ∈ {0, 1} (which corresponds to 'No' and 'Yes' respectively).In our implementation, we extend it to support multiple candidates by running the single-candidate elections in parallel for all  candidates and adding a zero-knowledge proof (ZKP) to constrain that only one candidate out of  may be chosen.Each ballot is uniquely identified by an index number .In our implementation, we chose the index number  to be incremental for each ballot.Each ballot  contains   ∈ {0, 1} ( = 0, … ,  − 1) votes for  candidates.When the voter selects a candidate, their ballot is generated by the server as follows.For each candidate  = 0, 1, … ,  − 1: 1. Assign   = 1 if the voter has chosen the th candidate;   = 0 otherwise.2. Compute an encrypted vote for the th candidate, consisting of   =  1 ⋅ (  +   ) and   =  2 ⋅   where   ∈  [0,  − 1] is a random secret, and '+∕⋅' are addition/multiplication operations on an elliptic curve respectively.3. Compute a 1-out-of −2 ZKP based on the Cramer-Damgård-Schoenmakers method [14] to prove that   is either 0 or 1 (i.e., the encrypted vote for each candidate is well-formed).
These per-candidate votes are then collated into an overall ballot , with an additional ZKP to prove that exactly one out of the  candidates has been chosen, i.e., ∑    = 1.We use Chaum-Pedersen's equality ZKP [13] to realize this.All the ZKPs implemented in our system are made non-interactive by applying the Fiat-Shamir heuristics [5].Unique indices of the election ID, the question number, the ballot number and the candidate number (where applicable) are included into the hash function to bind each ZKP with its unique context.
Casting a ballot comprises two steps (see Fig. 1 for an illustration).First, the voter chooses a candidate from the list.Second, the voter has the option to either cancel or confirm the ballot.In case of cancelling the ballot, the ballot is cancelled and the voter is redirected to Step 1 to vote again.In case of confirming the ballot, the ballot is cast and the voting session is finished.
A receipt for the ballot  consists of two parts, corresponding to the above two steps respectively.The first part is generated as soon as the voter chooses a candidate.It contains   and   for  = 0, 1, … ,  − 1 and the ZKPs.The receipt is displayed on the voter's voting page, which they can choose to print out.The same content is also posted on the public bulletin board together with a digital signature to prove data authenticity.The voter is encouraged to check that the receipt is the same as the one published on the bulletin board.To make this check easier, we adopt a truncated hash approach used in the Gateshead trial [15] by computing a truncated hash of 50 characters (in base-32 encoding), arranged in two rows and groups of 5 characters.This truncated hash is called the ''confirmation code'' on the receipt.It is sufficient for the voter to check the ''confirmation code'' on the receipt matches that on the public bulletin board.The full cryptographic data (including   ,   , ZKPs and digital signatures) are available on the bulletin board for public verification.
The second part of the receipt depends on whether the voter chooses to cancel or confirm their ballot.In case of cancelling the ballot, the chosen candidate (  ,  = 0, 1, … ,  − 1) is revealed on the receipt.The same content, together with the cryptographic random secrets   , is also published on the bulletin board.With   , anyone is able to decrypt   and   and check whether the decrypted results match the   values.This assures ''cast-as-intended''.A cancelled ballot does not add to the tally.After a voter cancels a ballot, they can vote again.
In the case of confirming the ballot, the receipt shows no additional information other than that the ballot has been ''confirmed'', and that the ballot is the encryption of either a 'Yes' vote or a 'No' vote.A voter is encouraged to check that the same receipt is published on the bulletin board.This provides assurance of ''recorded-as-cast''.The server keeps a running tally   for each candidate , and an aggregated secret   .The   and   values are initially zero and are updated during the voting phase for each confirmed ballot, i.e.,   ←   +   ,   ←   +   for  = 0, 1, … , .The individual values of   and   ( = 0, 1, … , ) are securely erased once a confirmed ballot is cast.At this point, not even the system knows which candidate a particular ballot is for, and the receipts reveal no information that would enable a coercer to deduce the vote.We note that a coercer could learn the vote by being present with the voter and observing how they cast the vote; however, this is a threat that generally applies to all remote voting applications (including postal voting).

Result phase
When the voting end time has passed, the system stops accepting new votes; any existing ballots that are neither confirmed nor cancelled are automatically cancelled.The system publishes the tally   and the aggregated secret   for all  candidates.The tally   for each candidate  ∈ [0,  − 1] can be verified as follows.We know that   = ∑    and   = ∑    should hold over the secret (and now erased)   and   values of all confirmed ballots C. Therefore, the following properties hold over the public values of confirmed ballots: and These two properties are defined on only public values and therefore can be checked by anyone.They are equivalent to checking the correctness properties on the secret values and thus the correctness of the tally.In our implementation, once an election is finished, we publish the full audit data in JSON format on the bulletin board so anyone can download and check.To facilitate public verification, we provide an open-source tool to allow anyone to verify that all ballots are ''talliedas-recorded''.One is also free to write their own verification tool since the verification algorithm is entirely public without any secret keys.

Durga Puja online voting trial
Ethics approval.The Durga Puja trial represents a joint collaboration between the academic research team and NKDA, which is the local authority governing the New Town city.The system was developed according to the NKDA requirements in Section 3.1.After the system was developed, it was internally tested by NKDA in several iterations before they officially approved its use for the Durga Puja trial.Meanwhile, the trial was also approved by the University of Warwick's research ethics committee.As part of the ethics approval process, it was agreed that we would not provide any awards to the winning candidates (apart from an honourable mention on the NKDA website), or make payments to participants of this trial.This was to avoid potential bias in favor of the system.The trial was agreed to run during the 2022 Durga Puja festival: starting on the 1st of October 2022, 12:00 AM and ending on the 5th of October 11:59 PM (Indian standard time).From 23 September to 30 September, NKDA issued a public call through their official website for the nomination of candidates for the 'block' and 'housing' categories respectively.In the end, 14 candidates were nominated for the 'block' category, and 18 candidates were nominated for the 'housing' category.For each category, the voting question is the same: ''Best Puja under citizen choice''.After the candidates, the voting question and the start/end times for the election were specified, the election setup was completed and the subsequent election management was automated.The online voting system started accepting votes at midnight (12:00 am) on 1st October 2022, when the Durga Puja festival in New Town officially began.Over the next 5 days, 543 voters participated with 506 cast votes recorded (see Fig. 2).After voting, each voter was provided with a web link to an anonymous survey using Google Form.In total, 95 voters filled in the survey.
The survey contains three sections.The first section includes questions about basic demographics, such as gender, age, education, and computer usage background.The second section includes 10 standard System Usability Scale (SUS) questions in order to evaluate the usability of the system.The third section includes a question asking the voter for their preference between postal voting and E2E verifiable online voting.

Trial results
In this section, we analyze the voting statistics and the collected surveys for usability evaluation, as well as possible correlations with demographics.

System usability scale scores and correlations
We adopt the standard SUS framework developed by John Brooke [16] for evaluating the usability of our system.The SUS framework consists of 10 statements.Respondents must indicate their agreement with these statements on a five-point Likert scale (1 = "strongly disagree", 2 = "disagree", 3 = "neutral", 4 = "agree", 5 = "strongly agree").This returns a score that can be compared against other systems.We use the original wording for the SUS questions, except that we change one statement "I think that I would like to use this system frequently" to "I think that I would like to use this system in the future".This follows the same change made to this SUS question in the Gateshead trial [15].
Using the SUS computation method, our mean SUS score is 79.55 with a standard deviation of 17.13.This is between ''good'' (SUS = 73) and ''excellent (SUS = 85) based on commonly used criteria [17].We observed that the main inconvenience for some voters was solving a CAPTCHA challenge while going through the OTP authentication.In ordinary cases, a user simply needs to click a tick-box to pass the reCAPTCHA v2, but Google sometimes prompts the voter to manually solve a CAPTCHA challenge (e.g., identifying traffic lights).This is decided by the Google server based on several factors, e.g., if the user has previously authenticated to a Google account in the browser.The use of reCAPTCHA v3 would reduce the need for this user interaction, but it requires a dedicated administrator to monitor the traffic and adjust the threshold accordingly.
Based on the Spearman correlation method, we find the SUS score has little correlation with age (Spearman correlation coefficient  = −0.065,and two-tailed  = 0.533) and education ( = 0.134,  = 0.219). 4 However, the SUS score is found weakly correlated with computer 4 If we remove ''postgraduate degree'', there remains no significant correlation between the SUS and education with  = 0.276 and  = 0.103.experience, with higher scores for users with more computer experience ( = 0.319,  = 0.002).This result is broadly consistent with a previous usability study of a DRE-ip implementation for a polling station voting trial at Gateshead, UK [15], in which the SUS score was found uncorrelated with the age, gender, or educational background but positively correlated with the voter's computer usage experience.
The final question in the anonymous survey asks the voter: ''If you have to vote remotely, which system do you prefer?''Voters are asked to choose a preference between two remote voting methods: postal voting and E2E verifiable online voting (as used in the trial).The choices are given in a 5-point Likert scale: 1 (''strongly prefer postal voting''), 2 (''prefer postal voting''), 3 (''neutral''), 4 (''prefer online voting'') and 5 (''strongly prefer online voting'').Fig. 3 summarizes the preferences from the voter feedback.The vast majority (89 or 93.7%) of participants responded that they prefer or strongly prefer online voting.This preference is found weakly correlated with SUS with those rating higher SUS scores more likely to prefer online voting ( = 0.38,  < 0.001).
We emphasize that the strong preference for online voting over postal voting in Fig. 3 is expressed within the context of an informal non-statutory election.The result may not necessarily generalize to statutory elections, where the election rules are different, and so are the voters' expectations.This will need to be studied further in the future.We note that voting as a basic democratic method is not limited to government elections; a person's democratic right can be exercised in many mundane voting scenarios, such as classroom voting, boardroom voting, and festival voting.In these scenarios, in-person voting using paper ballots is not always possible.When voting is conducted remotely, postal voting can prove costly especially when it needs to be done frequently.In that case, E2E verifiable online voting can become a possible alternative to postal voting.

Other statistics
Auditing rate.Our system recorded 506 cast votes during the 5-day trial.Among these votes, 12 were cancelled (or audited) votes while the remaining 494 were confirmed votes.This gives an auditing rate of 2.4%, which is similar to expectations from the literature when the voter is left to themselves to choose if they wish to confirm or cancel a ballot [15].In practice, the auditing rate can be increased by employing dedicated auditors whose task is to cancel votes and check cast-as-intended at any random time during the voting phase [5].
Completion rate.During the trial, 543 people (with distinct Indian mobile numbers) passed the OTP authentication and chose one of the closely the 3.03 ms empirical result shown in Table 2.All the other experimental measurements in Table 2 match our theoretical estimates based on the number of multiplications, except the ''Tally'' operation.This exception occurs because, for a large number of ballots, the cost of Eq. ( 1) is dominated not by the multiplication, but by the addition (i.e., computing ∑   and ∑   ).Hence, we need a different way to estimate the cost.Using the repeated squaring method, one multiplication approximately requires 256 + 128 = 384 additions on the NIST P-256 curve.For summing up   and   for 16 candidates, we need 2 × 16 × 10, 000 = 320, 000 additions, which is equivalent to 320, 000∕384 = 833 multiplications.For each candidate, we require 2 multiplications for the tally verification in Eq. ( 1).So all together that is equivalent to 833 + 2 × 16 = 865 multiplications.Given that each multiplication costs 0.096 ms, the total cost is estimated to be 0.096 × 865 = 83.04ms for 10,000 ballots, i.e., 0.008 ms per ballot.This approximately matches the 0.01 ms experimental measurement per ballot shown in Table 2.

Related work
Many case studies have been examined in the literature regarding the deployment and usability analysis of verifiable e-voting systems.These studies may largely be classified into those for polling station voting [15,18,19], where a voter must cast their vote in-person, or for remote voting [20,21], where a voter is permitted to cast their vote from any location, for instance through the Internet.Example case studies for remote voting include the analyses of Swiss Post's voting system by Marky et al. [20] and Volkamer et al. [21].Additionally, Acemyan et al. provide baseline data for the usability of the Helios voting system [22].In this section, we will focus on comparing with Helios, since both Helios and our system are end-to-end verifiable, whilst the Swiss Post voting system is currently not [20].
Helios [9] is a web-based voting system, which initially utilized the Sako-Kilian mix-net [23] in Version 1.0, but later switched to use homomorphic encryption in Version 2.0.Helios 2.0 implements the Cramer-Gennaro-Schoenmakers (CGS) voting protocol [14], which aggregates encrypted ballots based on homomorphism and then employs a set of TAs to perform threshold decryption.It additionally incorporates Benaloh's voter-initiated auditing method [24] to ensure ''cast as intended''.In 2009, Helios 2.0 was used to elect the president of Université catholique de Louvain (UCL) [9].Since Helios 1.0 has been replaced by Helios 2.0, by Helios, we refer to Helios 2.0 thereafter.
Acemyan et al. assessed the usability of Helios through a withinsubjects study of 37 participants [22].A mock election was created through the Helios website in 2014.According to Acemyan et al. although 95% of voters perceived that they had cast the vote through Helios, only 60% actually had.This discrepancy was mainly because of the way that Helios implemented voter auditing according to Beneloh's challenge [24].Anyone can choose candidates from a list and perform auditing by cancelling votes without being authenticated.If a voter opts to confirm the vote, they may think voting has finished, but they still need to pass authentication to actually cast the vote.This issue could be addressed by adding an explicit warning on the voting page to prompt the voter to log in and finish voting.In our system, voters are authenticated at the start of a voting session, hence avoiding any potential confusion.Our E2E voting system differs from Helios in several aspects.First, instead of implementing a TA-based CGS protocol [14], we adopt a TA-free DRE-ip protocol [5].As reported by the Helios authors in the UCL trial [9], finding and managing the TAs proved to be a ''particularly difficult issue''.As a mitigating measure, the Helios website now prompts the election creator to choose the Helios server as a single TA and discourages defining more TAs due to the additional complexity involved. 6In a single TA-based Helios election, a compromise of the server (i.e., the TA's private key) breaks the secrecy of all votes.In our system, there is no TA (or TA's private key) and a compromise of the server only reveals the partial tally at the time of compromise, which minimizes information leakage [5].For both Helios and DRE-ip, voter privacy can be enhanced through anonymity: only authenticated voters are allowed to vote but their real identities are unknown to the system.Anonymous voting can be realized in a polling station through physical means, e.g., by assigning random passcode slips to voters [15].For remote voting, a similar procedure may be used to distribute authentication credentials to enable legitimate voters to vote anonymously.
Second, while Helios allows a voter to audit votes without authentication as specified in Benaloh's challenge [24], we require voters to be authenticated first according to the DRE-ip specification.Based on the trial, we find that this helps provide a more natural and intuitive voting process for ordinary voters, as well as a simpler voter-initiated auditing procedure as explained below.
Third, Helios requires a user to verify an audited ballot by copying and pasting the cryptographic data from a voting page to the text field of a verification page running the JavaScript code, but this can prove difficult for ordinary voters [25].The verification of an audited ballot in our system is simpler as the voter only needs to check if the receipt of a cancelled ballot matches that published on the public bulletin board based on DRE-ip [5].However, doing the same in Helios appears difficult because a user is unauthenticated when auditing a ballot; allowing an unauthenticated user to post data on the public bulletin board of an election can expose the system to a Denial of Service attack.

Conclusion
Empirical studies play an important role in e-voting research to validate not only the assumptions of a theoretical voting protocol but also the feasibility of the system from a voter's perspective.Despite extensive research on E2E verifiable e-voting, such studies remain limited: few E2E voting systems have been implemented and used in practice.In this paper, we present an E2E online voting system based on DRE-ip and conduct a trial among the New Town residents in India as part of the 2022 Durga Puja festival celebration.Based on the voter feedback, participants generally found our system easy to use.Our trial experience also shows that the removal of tallying authorities significantly simplifies not only the implementation but also the election management, making E2E e-voting more practical than before.

Table 1
Comparison of remote voting systems in terms of verifiability.