OpenVoting: Recoverability from Failures in Dual Voting

Abstract

In this paper we address the problem of recovery from failures without re-running entire elections when elections fail to verify. We consider the setting of dual voting protocols, where the cryptographic guarantees of end-to-end verifiable voting (E2E-V) are combined with the simplicity of audit using voter-verified paper records (VVPR). We first consider the design requirements of such a system and then suggest a protocol called OpenVoting, which identifies a verifiable subset of error-free votes consistent with the VVPRs, and the polling booths corresponding to the votes that fail to verify with possible reasons for the failures.

1 Introduction

Conducting large-scale public elections in a dispute-free manner is not an easy task. On the one hand, there are end-to-end verifiable voting (E2E-V) systems [1, 4, 8, 11, 24] that provide cryptographic guarantees of correctness. Although the guarantees are sound, these systems are not yet very popular in large public elections. As the German Constitutional Court observes [18], depending solely on cryptographic guarantees is somewhat untenable as verification of election results requires expert knowledge. Moreover, in case voter checks or universal verifications fail, the E2E-V systems do not provide easy methods of recovery without necessitating complete re-election [6].

On the other hand, there are systems that rely on paper-audit trails to verify electronic tallies [16, 21, 25]. These systems maintain reliable records of cleartext voter-marked paper ballots or voter-verified paper records (VVPRs) alongside electronic vote records. They use electronic counting for efficiency and conduct easy-to-understand statistical audits, called risk-limiting audits (RLAs), to demonstrate that the electronic winners match the winners that would be declared by a full paper count. In case of conflict, the electronic outcome is suggested to be replaced by the paper one. However, these systems require the electorate to trust that the paper records correctly represent voter intent and are not corrupted in the custody chain from the time of voting to that of counting or auditing.

Dual voting approaches, where the voting protocols support simultaneous voting for both the cryptographic and the VVPR-based systems [4, 5, 12, 13, 17, 22], combine the cryptographic guarantees of E2E-V systems with the simplicity and adoptability of paper records. However, in most existing dual voting systems, one typically ends up running two parallel and independent elections, only coupled loosely through simultaneous voting for both in the polling booth. If the electronic and paper record systems are not tightly coupled, and demonstrably in one-to-one correspondence, then it begs the questions: which ought be the legal definition of the vote, and, in case of a tally mismatch, which should be trusted? Why? And how to recover from errors?

It appears that existing approaches either do not provide any recovery mechanism or recover by privileging VVPR counts over electronic counts. In large public elections running simultaneously at multiple polling booths per constituency, failures due to intended or unintended errors by different actors are expected. Polling officers may upload wrong encrypted votes, backend servers may decrypt votes incorrectly, paper records may be tampered with during the custody chain, and voters may put bogus votes in ballot boxes to discredit the election. Discarding the entire election due to failures caused by some bad actors or completely trusting the VVPRs are both unsatisfactory solutions.

In this paper, we study the problem of recoverability of a dual voting protocol from audit failures. We consider large, multi-polling booth, first-past-the-post elections like the national elections in India. We observe that except for backend failures, most of the other failures are due to localised corruption of individual polling booths. Therefore, we propose to identify the offending polling booths and perform a local re-election—if at all required—only at those polling booths. Errors—despite the best efforts to minimise them—are inevitable in large elections and such localised recovery may considerably improve the election’s overall robustness and transparency.

However, recoverability has a natural tradeoff with vote secrecy. For example, a naive approach that simply publishes and audits votes for each polling booth reveals voting statistics of each booth. In electoral contexts where voters are assigned a specific polling booth according to their residential neighbourhoods, with only a few thousand voters per booth, e.g., in India, revealing booth-level voting statistics poses a significant risk of localised targeting and coercion [3]. Our approach minimises booth-level voting data exposure, disclosing only what is absolutely necessary for recovery.

Main Contributions. 1) We analyse the design requirements for a recoverable and secrecy-preserving dual voting protocol (Sect. 2). 2) We formalise the notion of recoverability and secrecy in terms of the capability to verifiably identify polling booths contributing to verification failures and extract a verifiable subset of error-free votes in zero-knowledge (Sect. 3). 3) We propose a novel dual-voting protocol called OpenVoting that satisfies our notions of recoverability and secrecy (Sect. 4).

Related Work. Dual voting was introduced by Benaloh [5], following which multiple dual voting protocols emerged [4, 12, 13, 17, 22]. Bernhard et al. [6] gives a comprehensive survey of the tradeoffs and open problems in E2E-V and RLA-based voting.

Rivest [23] proposed the notion of strong software independence that is similar to our notion of recoverability. It demands that a detected change or error in an election outcome (due to a change or error in the software) can be corrected without re-running the (entire) election. However, “correcting” errors without re-running even parts of an election requires a ground truth, which is usually assumed to be the paper audit trail. Instead, we propose partial recoverability via fault localisation, without completely trusting either paper or electronic votes. The notion of accountability [15] is also related, but it is focused on assigning blame for failures and not on recovering from them.

2 Design Requirements

In a typical dual voting protocol, the vote casting process produces a) a VVPR containing the voter’s vote in cleartext and b) a voter receipt containing an encryption of the vote. The encrypted votes are published on a bulletin board, typically by a polling officer, and are processed by a cryptographic backend to produce the electronic tally. The backend typically consists of multiple independent servers which jointly compute the tally from the encrypted inputs, provide a proof of correctness, and preserve vote secrecy unless a threshold number of servers are corrupted. VVPRs counted together produce the paper tally.

Our high-level goal is to publicly verify whether both tallies represent true voter intents and whether all public outputs are consistent with each other. If not, the aim of recovery is to identify booths contributing to the inconsistencies, and segregate the outputs produced by other error-free booths, without leaking any additional information. For this, the protocol design must fundamentally have the following features:

• 1. The backend must publish individual decrypted votes with matching identifiers with the VVPRs¹, to narrow down tally inconsistencies to individual vote mismatches.

• 2. The encrypted votes must have voter and booth identifiers. The former enable matching with voter receipts; the latter enable identifying booths in case of errors.

• 3. The decrypted votes and VVPRs and their identifiers must be unlinkable to encrypted votes, voter receipts or voter identifiers to ensure vote secrecy. They should also be unlinkable to the booth identifiers to hide booth-level voting statistics.

• 4. For the same reason, VVPRs should be revealed and counted only after aggregating them over all the polling booths.

The encrypted and decrypted votes must be published on two public bulletin boards to enable voters to match their receipts and public verification of the electronic tally. It will also be helpful to upload all VVPRs after scanning, and as many voter receipts as possible, to two other bulletin boards for better transparency and public verifiability. We depict such a design in Fig. 1.

Fig. 1.

A recoverable dual voting protocol design. The VVPR for a voter with identifier $\textsf{vid}_i$ voting at booth $\textsf{booth}_i$ contains a ballot identifier $\textsf{bid}_i$ and cleartext vote $v_i$. Her encrypted vote $c_i$ encrypts a value, e.g., $(\textsf{bid}_i,v_i)$, that when decrypted can be uniquely matched with the corresponding VVPR. Decrypted votes are published by backend servers $\mathcal {M}_{1}, \dots ,\mathcal {M}_{m}$ in a permuted order under a secret shared permutation $\pi$ such that $(\textsf{bid}'_{i}, {v}_{i}')$ $=$ $(\textsf{bid}_{\pi (i)}, {v}_{\pi (i)})$. Note that $n_\textsf{c}$ and $n_\textsf{v}$ denote the number of encrypted votes and decrypted votes respectively.

Note that the public outputs in Fig. 1 are effectively claims endorsed by various entities as to what should be the correct vote: receipts by voters, encrypted votes by polling officers, decrypted votes by the backend servers, and VVPRs by the VVPR counting authorities. We group disputes between these claims into input-phase failures, for mismatches between published voter receipts and encrypted votes, mixing-phase failures, for mismatches between encrypted votes and decrypted votes, and output-phase failures, for mismatches between decrypted votes and VVPRs (see Fig. 2). Further, we categorise claims of receipts not encrypting voter intents correctly as cast-as-intended failures. Given these failures, recoverability requires an audit protocol that verifies whether the different claims for a given vote are consistent, resolves disputes otherwise, and narrows down the affected votes when the disputes are unresolvable.

To recover from input-phase failures, it is not sufficient if a statistically significant sample of voters from the entire constituency verify their receipts, because in case of any failure, all the uploaded encrypted votes become untrustworthy. Thus, the population for sampling must be each polling booth. This does increase the voter verification overhead, but offers better localisation of errors and recovery.

Recoverability from mixing-phase failures requires that in case the output list of decrypted votes is not correct, individual failing entries—encrypted votes whose decryptions were not available in $V$ and individual decrypted votes that were not decrypted by any encrypted vote on $C$—should be verifiably identified by the backend servers. And, this must be achieved without leaking any additional information.

Recoverability from output-phase failures requires identifying which of the electronic vote and the VVPR represents the voter’s intent. This may be possible in some cases but not always. For example, if the voter’s receipt is available on $R$, then the dispute can be resolved if one can verify in zero-knowledge that the receipt encrypted the electronic vote and not the paper one, or vice versa.

In some cases, the disputes may not be resolvable at all. Consider case $\textsf{FO}_3$ in Fig. 2 and suppose the receipt is not available. $\textsf{FO}_3$ may be due to a) the polling officer uploading an encrypted vote not matching the voter’s receipt; b) the voter dropping a bogus VVPR into the ballot box; c) a malicious agent altering the VVPRs post-polling; or d) the backend servers not decrypting the uploaded encrypted vote correctly. Different cases point to failures in either the electronic vote or the VVPR and it is not possible to identify the true voter intent. Thus, a conservative way to recover from this situation is to identify the polling booth where the dispute may have originated and conduct only a local re-election at this booth. This must be done without revealing polling booth statistics of at least the uncorrupted polling booths.

Fig. 2.

Potential failures given public outputs $(R,C,V,P)$.

The required action in all the above cases can be reduced to the backend proving in zero-knowledge that an encrypted vote corresponds to one of a set of decrypted votes (a distributed ZKP of set-membership [2]), or that a clear-text vote is a decryption of one of a set of encrypted votes (a distributed ZKP of reverse set-membership [2]).

Cast-as-intended failures may typically happen in two ways. First, ballots may be malformed. Protection against this threat requires a separate audit of a statistically significant sample of ballots before vote casting. Recoverability additionally requires ballot audits to be performed per polling booth. Second, ballots or receipts may be marked incorrectly. In dual voting systems based on hand-marked ballots, the voter may mark the encrypted and the VVPR parts differently, leading to failures. Although this is easily detected and invalidated during VVPR audit, fixing accountability may be difficult and hence voters may do this deliberately to discredit the election. In systems based on ballot marking devices (BMD), such voter errors are avoided but a dispute may be raised that the ballot marking is not according to the voter’s choice. Such a dispute between a man and a machine is unresolvable and the only recourse is to allow the voter to revote. This may however cause a deadlock, which can only be resolved through a social process. Still, a BMD should be a preferred option for dual voting since it minimises voter-initiated errors.

3 Formalisation

We now formalise the requirements outlined in the previous section. Given a positive integer x, let [x] denote the set $\{1,\dots ,x\}$. We consider a dual-voting protocol involving $\alpha$ candidates, n voters $(\mathcal {V}_{i})_{i\in [n]}$, $\tau$ ballot generators $(\mathcal {G}_{t})_{t\in [\tau ]}$, $\ell$ polling booths consisting of polling officers $(\mathcal {P}_{j})_{j\in [\ell ]}$, BMDs $(\mathcal {D}_{j})_{j\in [\ell ]}$ and physical ballot boxes $(\mathcal {B}_{j})_{j\in [\ell ]}$, m backend servers $(\mathcal {M}_{k})_{k\in [m]}$, and an auditor $\mathcal {A}$. We also assume existence of a public bulletin board where lists $R$, $C$, $V$ and $P$ are published. We consider a protocol structure $(\textsf{Setup}$, $\textsf{BallotGen}$, $\textsf{Cast}$, $\textsf{Tally}$, $\textsf{BallotAudit}$, $\textsf{ReceiptAudit}$, $\textsf{TallyAudit})$ where:

• $\textsf{Setup}$ is a protocol involving $(\mathcal {G}_{t})_{t\in [\tau ]}$, $(\mathcal {P}_{j})_{j\in [\ell ]}$ and $(\mathcal {M}_{k})_{k\in [m]}$ to generate public/private key pairs and other public election parameters.

• $\textsf{BallotGen}$ is a protocol involving $(\mathcal {G}_{t})_{t\in [\tau ]}$ to securely print a sealed ballot given a booth identifier $j \in [\ell ]$.

• $\textsf{Cast}$ is the vote casting protocol involving $\mathcal {V}_{i}$ and $\mathcal {P}_{j}$, $\mathcal {D}_{j}$, $\mathcal {B}_{j}$ at booth $j \in [\ell ]$ assigned to $\mathcal {V}_{i}$. $\mathcal {V}_{i}$’s input is its intended vote v and a ballot b. The protocol outputs a voter receipt r, an encrypted vote c and a VVPR p such that p gets dropped in ballot box $\mathcal {B}_{j}$, $\mathcal {V}_{i}$ takes r home and $\mathcal {P}_{j}$ uploads c on $C$. The voter may or may not publish r on $R$. The VVPR is published on $P$ after aggregating VVPRs from all the booths.

• $\textsf{Tally}$ is the vote processing/tallying protocol involving $(\mathcal {M}_{k})_{k\in [m]}$ where they take as input the encrypted votes $({c}_{i})_{i \in [n]}$ published on $C$, permute and decrypt them and publish a list $({v}_{i}')_{i \in [n]}$ of decrypted votes on $V$.

• $\textsf{BallotAudit}$ is a protocol involving $\mathcal {A}$ and $\mathcal {P}_{j}$ executed at each booth j to verify if ballots at booth j are well-formed.

• $\textsf{ReceiptAudit}$ is a protocol involving $\mathcal {A}$ and the voters to verify that voter receipts at booth j match those uploaded on list C.

• $\textsf{TallyAudit}$ is a protocol involving $\mathcal {A}$, $(\mathcal {M}_{k})_{k\in [m]}$ and $(\mathcal {G}_{t})_{t\in [\tau ]}$ to verify whether the electronic and paper tallies are correct and narrow down errors if not. It takes as input all published lists $(R,C,V,P)$ and lets $\mathcal {A}$ output a tuple $(J^*, V^*)$ where $J^*$ denotes the set of booths that contributed potentially outcome-changing failures and $V^*$ denotes the set of votes from booths not in $J^*$ ($\mathcal {A}$ may also be aborted). The expected usage of the $(J^*,V^*)$ output is that in case of failures/disputes, the election could be rerun at the booths in $J^*$ and the rerun results could be merged with the recovered partial tally from $V^*$ to obtain the complete election tally. Results are announced to the general public only after $\textsf{TallyAudit}$ has finished.

Note that although the above audits are performed by different auditors (even voters) at different times and places, we simplify by representing all the auditors by $\mathcal {A}$.

Let $\epsilon _{\textsf{b}}$ denote the probability that $\textsf{BallotAudit}$ passes at some booth j yet a receipt from the booth does not encrypt the voter’s intent correctly, and $\epsilon _{\textsf{r}}$ denote the probability that $\textsf{ReceiptAudit}$ passes for booth j yet a receipt from the booth is not uploaded correctly. Further, let $R^*\subseteq R$, $C^*\subseteq C$ and $P^*\subseteq P$ respectively denote receipts, encrypted votes and VVPRs from booths not in $J^*$. Finally, let failures in a tuple (R, C, V, P) be as defined in Fig. 2 with the added condition that if a receipt or encrypted vote from a booth fails with input-phase or cast-as-intended failures, then all receipts and encrypted votes from that booth are considered as failures.

Definition 1 models our notion of recoverability parametrised by probabilities $\epsilon _{\textsf{b}}$ and $\epsilon _{\textsf{r}}$ denoting the effectiveness of ballot and receipt audits. The case when $J^*$ is empty denotes that no rerun is required at any booth, either because the election ran completely correctly, or because the number of failures are small compared to the reported winning margin. When non-empty, $J^*$ should exactly be the set of booths where re-run is required because of failures that may affect the final outcome and votes $V^*$ must be consistent with receipts, encrypted votes and VVPRs from booths not in $J^*$.

Note that the auditor is allowed to abort the $\textsf{TallyAudit}$ protocol, since if the mix-servers and the ballot generators holding the election secrets do not cooperate, then recovery cannot happen. This is not an issue because unlike polling booth failures, these failures are centralised and non-cooperation directly puts the blame on these entities.

Definition 1 (Recoverability)

A voting protocol $(\textsf{Setup}$, $\textsf{BallotGen}$, $\textsf{Cast}$, $\textsf{Tally}$, $\textsf{BallotAudit}$, $\textsf{ReceiptAudit}$, $\textsf{TallyAudit})$ is recoverable by the audit protocols if for all polynomially bounded adversaries corrupting $(\mathcal {G}_{t})_{t\in [\tau ]}$, $(\mathcal {M}_{k})_{k\in [m]}$, $(\mathcal {P}_{j})_{j\in [\ell ]}$, $(\mathcal {D}_{j})_{j\in [\ell ]}$ and $(\mathcal {B}_{j})_{j\in [\ell ]}$ such that $\mathcal {A}$ outputs a tuple $(J^*, V^*)$ and does not abort, the following conditions hold true with probability only negligibly smaller than $1 - \ell (\epsilon _{\textsf{b}} + \epsilon _{\textsf{r}})$:

• if $J^*$ is empty, then the number of failures in $(R^*, C^*, V^*, P^*)$ is less than the reported winning margin computed from $V$; and

• if $J^*$ is non-empty, then $(R^*, C^*, V^*, P^*)$ does not contain any failures and $J^*$ is exactly the set of booths that contributed some failing receipt in $R$, some failing encrypted vote in $C$, or some failing VVPR in $P$.

Definition 2 models that in the presence of the $\textsf{TallyAudit}$ protocol, the standard vote secrecy guarantee is maintained except that polling booth statistics of the booths contributing some failing items are revealed. This is generally an unavoidable tradeoff.

Definition 2 (Vote Secrecy with Recoverability)

A voting protocol $(\textsf{Setup}$, $\textsf{BallotGen}$, $\textsf{Cast}$, $\textsf{Tally}$, $\textsf{BallotAudit}$, $\textsf{ReceiptAudit}$, $\textsf{TallyAudit})$ protects vote secrecy with recoverability if no polynomially bounded adversary controlling the auditor $\mathcal {A}$, $(\mathcal {P}_{j})_{j\in [\ell ]}$, $(\mathcal {D}_{j})_{j\in [\ell ]}$, $(\mathcal {G}_{t})_{t \in [\tau ] \setminus \{t^*\}}$ for some $t^* \in [\tau ]$, $(\mathcal {M}_{k})_{k \in [m] \setminus \{k^*\}}$ for some $k^* \in [m]$, and $(\mathcal {V}_{i})_{i \in [n] \setminus \{i_0,i_1\}}$ for some $i_0,i_1 \in [n]$ can distinguish between the following two worlds except with negligible probability:

• (World 0) $\mathcal {V}_{i_0}$ votes $v_0$ at booth $j_0$ and $\mathcal {V}_{i_1}$ votes $v_1$ at booth $j_1$, and

• (World 1) $\mathcal {V}_{i_0}$ votes $v_1$ at booth $j_0$ and $\mathcal {V}_{i_1}$ votes $v_0$ at booth $j_1$,

where $v_0,v_1$ are any two valid votes and for each failure from booth $j_0$, the adversary must create an identical failure (same failure type and affected vote) from booth $j_1$.

4 The OpenVoting Protocol

4.1 Preliminaries

Notation. Let $\mathbb {G}_{1}, \mathbb {G}_{2}, \mathbb {G}_{T}$ denote cyclic groups of prime order q ($q\gg \alpha ,m,n,\ell$) such that they admit an efficiently computable bilinear map $e: \mathbb {G}_{1}\times \mathbb {G}_{2}\rightarrow \mathbb {G}_{T}$. We assume that the n-Strong Diffie Hellman (SDH) assumption [7] holds in $(\mathbb {G}_{1}, \mathbb {G}_{2})$, the decisional Diffie-Hellman (DDH) and the discrete logarithm (DL) assumptions hold in $\mathbb {G}_{1}$, and that generators $g_1, h_1 \in \mathbb {G}_{1}$ are chosen randomly (say as the output of a hash function) so that nobody knows their mutual discrete logarithm.

Traceable Mixnets [2]. Traceable mixnets extend traditional mixnets [14] to enable the distributed ZKPs of set membership mentioned in Sect. 2. Thus, we use them as our cryptographic backend. In traceable mixnets, the backend servers, often also called mix-servers, can collectively prove answers to the following queries in zero-knowledge:

• TraceIn: whether a ciphertext c (from the mixnet’s input ciphertext list) encrypts a value in a subset of output plaintexts (denoted as $({v}_{i}')_{i \in I'}$ for some $I' \subseteq [n]$).

• TraceOut: whether a plaintext v (from the mixnet’s output plaintext list) is encrypted in one of a subset of input ciphertexts (denoted as $({c}_{i})_{i \in I}$ for some $I \subseteq [n]$.).

There are also batched versions of these queries called BTraceIn and BTraceOut, which prove multiple TraceIn and TraceOut queries together.

Formally, a traceable mixnet $\varPi _{\textsf{TM}}$ is a protocol between a set of senders $S_1,\dots ,S_n$, a set of mix-servers $(\mathcal {M}_{k})_{k \in [m]}$ and a querier $Q$ and consists of algorithms/sub-protocols $(\textsf{Keygen}, \textsf{Enc}, \textsf{Mix}, \textsf{BTraceIn}, \textsf{BTraceOut})$ where:

• $\textsf{Keygen}$ is a distributed key generation protocol involving $(\mathcal {M}_{k})_{k \in [m]}$ that outputs a mixnet public key $\textsf{mpk}$ and secret keys ${\textsf{msk}}^{(k)}$ for each mix-server $\mathcal {M}_{k}$.

• $\textsf{Enc}$ is the encryption algorithm that a sender $S_i$ uses to create a ciphertext ${c}_{i}$ encrypting its secret input ${v}_{i}$ against $\textsf{mpk}$.

• $\textsf{Mix}$ is the mixing protocol involving $(\mathcal {M}_{k})_{k \in [m]}$ that takes as input the list of ciphertexts $({c}_{i})_{i \in [n]}$ uploaded by $(S_i)_{i \in [n]}$ and outputs a list of permuted plaintexts $({v}_{i}')_{i \in [n]}$ and a secret witness ${\omega }^{(k)}$ for each $\mathcal {M}_{k}$.

• $\textsf{BTraceIn}$ is a protocol involving $(\mathcal {M}_{k})_{k \in [m]}$ and $Q$ that takes as input $({c}_{i})_{i \in [n]}$ and $({v}_{i}')_{i \in [n]}$ and index sets $I,I' \subseteq [n]$ (each $\mathcal {M}_{k}$ additionally uses ${\omega }^{(k)}$). At the end of the protocol, $Q$ either outputs the subset of ciphertexts $\{{c}_{i}\}_{i \in I}$ that encrypt some plaintext in $\{{v}_{i}'\}_{i \in I'}$ or aborts.

• $\textsf{BTraceOut}$ is a protocol involving $(\mathcal {M}_{k})_{k \in [m]}$ and $Q$ that takes exactly the same inputs as $\textsf{BTraceIn}$. In this case, $Q$ either outputs the subset of plaintexts $\{{v}_{i}'\}_{i \in I'}$ that are encrypted by some ciphertext in $\{{c}_{i}\}_{i \in I}$ or aborts.

The soundness property of traceable mixnets states that an adversary controlling all $(\mathcal {M}_{k})_{k \in [m]}$ cannot make $Q$ output an incorrect set. Their secrecy property states that an adversary controlling $(\mathcal {M}_{k})_{k \in [m] \setminus \{k^*\}}$ for some $k^* \in [m]$, $Q$ and $(S_i)_{i \in [n] \setminus \{i_0,i_1\}}$ for some $i_0,i_1 \in [n]$ cannot distinguish between a world where $(S_{i_0},S_{i_1})$ respectively encrypt $(v_0,v_1)$ and the world where they encrypt $(v_1,v_0)$, if the $\textsf{BTraceIn}$ and $\textsf{BTraceOut}$ query outputs do not leak this information, i.e., if in all $\textsf{BTraceIn}$ queries, $v_0 \in \{{v}_{i}'\}_{i \in I'}$ iff $v_1 \in \{{v}_{i}'\}_{i \in I'}$ and in all $\textsf{BTraceOut}$ queries, $i_0 \in I$ iff $i_1 \in I$.

An Instantiation of Traceable Mixnets. [2] also provides a concrete instantiation of a traceable mixnet, which we use. In this instantiation, $\textsf{mpk}$ is of the form $((\textsf{pk}_{\mathcal {M}_{k}})_{k \in [m]}$, $\textsf{pk}_{\textsf{EG}}$, $\textsf{pk}_{\textsf{Pa}})$, where $\textsf{pk}_{\mathcal {M}_{k}}$ is the public key of any IND-CPA secure encryption scheme $\textsf{E}$, and $\textsf{pk}_{\textsf{EG}}$ and $\textsf{pk}_{\textsf{Pa}}$ are respectively public keys of $\textsf{E}_{\textsf{EG}}^{\textsf{th}}$, the threshold ElGamal encryption scheme [10] with message space $\mathbb {G}_{1}$, and $\textsf{E}_{\textsf{Pa}}^{\textsf{th}}$, the threshold Paillier encryption scheme proposed in [9] with message space $\mathbb {Z}_N$ for an RSA modulus N. The secret key ${\textsf{msk}}^{(k)}$ for each $\mathcal {M}_{k}$ consists of the secret key $\textsf{sk}_{\mathcal {M}_{k}}$ corresponding to $\textsf{pk}_{\mathcal {M}_{k}}$ and the $k^{\text {th}}$ shares of the secret keys corresponding to $\textsf{pk}_{\textsf{EG}}$ and $\textsf{pk}_{\textsf{Pa}}$. Further, $\textsf{Enc}$ on input a value $v \in \mathbb {Z}_{q}$ outputs a ciphertext of the form $(\epsilon , \gamma , ({\textsf{ev}}^{(k)},{\textsf{er}}^{(k)})_{k \in [m]}, \rho _{\gamma }, \epsilon _r)$, where

• $\epsilon \leftarrow \textsf{E}_{\textsf{Pa}}^{\textsf{th}}.\textsf{Enc}(\textsf{pk}_{\textsf{Pa}}, v)$ is an encryption of v (interpreted as $v \in \mathbb {Z}_N$) under $\textsf{E}_{\textsf{Pa}}^{\textsf{th}}$,

• $\gamma = g_1^vh_1^r$ is a Pedersen commitment [20] to v in $\mathbb {G}_{1}$ under randomness $r \in \mathbb {Z}_{q}$,

• ${\textsf{ev}}^{(k)} \leftarrow \textsf{E}.\textsf{Enc}(\textsf{pk}_{\mathcal {M}_{k}}, {v}^{(k)})$ is an encryption of a secret share ${v}^{(k)}$ of v,

• ${\textsf{er}}^{(k)} \leftarrow \textsf{E}.\textsf{Enc}(\textsf{pk}_{\mathcal {M}_{k}}, {r}^{(k)})$ is an encryption of a secret share ${r}^{(k)}$ of r,

• $\rho _{\gamma }\leftarrow \textsf{NIZKPK}\{(v,r): \gamma = g_1^v h_1^r\}$ is a noninteractive ZKP of knowledge of the opening of $\gamma$, and

• $\epsilon _r \leftarrow \textsf{E}_{\textsf{Pa}}^{\textsf{th}}.\textsf{Enc}(\textsf{pk}_{\textsf{Pa}}, r)$ is an encryption of r (interpreted as $r \in \mathbb {Z}_N$) under $\textsf{E}_{\textsf{Pa}}^{\textsf{th}}$.

In our protocol, the encrypted votes are encryptions under $\textsf{Enc}$, where we instantiate scheme $\textsf{E}$ with the (non-threshold) Paillier encryption scheme [19]. We need it for its following homomorphic property: given two Paillier ciphertexts $c_1,c_2$ encrypting messages $m_1,m_2 \in \mathbb {Z}_{q}$ respectively ($m_1,m_2$ interpreted as messages in $\mathbb {Z}_N$), the ciphertext $c_1c_2$ encrypts the message $m_1+m_2 \mod N = m_1+m_2$ if $N>2q$. We also require a public-key digital signature scheme $\varPi _{\textsf{S}}:= (\textsf{Keygen}$, $\textsf{Sign}$, $\textsf{Ver})$ with the usual existential unforgeability property under chosen message attacks (EUF-CMA).

Fig. 3.

Overview of the OpenVoting protocol: w represents the candidate index in the ballot and $\dot{w}$ represents the voter’s choice.

4.2 The Proposed Protocol

Figure 3 depicts the high-level OpenVoting protocol. Two ballot generators ($\mathcal {G}_{1}$ and $\mathcal {G}_{2}$) jointly generate sealed ballots to protect voter-vote association from both. Voters use the sealed ballots and a BMD to cast their votes. Each ballot contains two halves. The BMD prints the voter’s choice on both halves without learning the vote. The left half becomes the VVPR and is deposited by the voter in a physical ballot box, while the right half becomes the voter receipt. Polling officers scan the voter receipts and upload the encrypted votes to $C$. The encrypted votes are processed by a traceable mixnet backend to produce decrypted votes V. Voters can verify their receipts against the encrypted votes, and VVPRs can be matched with the decrypted votes. The tally audit process uses the traceable mixnet’s querying mechanism to identify polling booths contributing to failures without leaking additional information. Results are announced only after this audit step. Now we describe the sub-protocols of OpenVoting in detail.

Setup. During the $\textsf{Setup}$ protocol, $\mathcal {G}_{1}$ and $\mathcal {G}_{2}$ generate public/private keys $\textsf{pk}_{\mathcal {G}_{1}}, \textsf{sk}_{\mathcal {G}_{1}}$ and $\textsf{pk}_{\mathcal {G}_{2}}, \textsf{sk}_{\mathcal {G}_{2}}$ under $\varPi _{\textsf{S}}$. Polling officers $(\mathcal {P}_{j})_{j \in [\ell ]}$ also generate public/private keys $(\textsf{pk}_{\mathcal {P}_{j}}, \textsf{sk}_{\mathcal {P}_{j}})_{j \in [\ell ]}$ under $\varPi _{\textsf{S}}$. Mix-servers $(\mathcal {M}_{k})_{k \in [m]}$ jointly run the $\varPi _{\textsf{TM}}.\textsf{Keygen}$ protocol of the traceable mixnet to generate the mixnet public key $\textsf{mpk}$ and individual secret keys $({\textsf{msk}}^{(k)})_{k \in [m]}$ for each $(\mathcal {M}_{k})_{k \in [m]}$. An official candidate list $(\textsf{cand}_0,\dots ,\textsf{cand}_{\alpha -1})$ is created such that $\textsf{cand}_a$ denotes the $a^{\text {th}}$ candidate.

Ballot Design. Our ballot (Fig. 3 - left) customises the Scratch & Vote ballot [1] for dual voting and BMD support. It consists of two halves connected by a perforated line. The left half serves as the VVPR, while the right half serves as the voter receipt. These halves are unlinkable after the vote is cast.

The left half includes a randomly drawn ballot identifier $\textsf{bid}$ from $\mathbb {Z}_q$. It displays a circular rotation of the official candidate list. For each $w \in \{0,\dots ,\alpha -1\}$, row w corresponds to the candidate $\textsf{cand}_{\textsf{bid}+ w \bmod {\alpha }}$. For example, if the official candidate list is $(\text {``Alice''}, \text {``Bob''}, \text {``Carol''})$, and $\textsf{bid}=302$, the candidate printed on row $w=1$ would be $\textsf{cand}_{302+1 \bmod 3} = \textsf{cand}_0$ (i.e., “Alice”). The right half contains corresponding encryptions $c_{w}$ obtained by running the $\varPi _{\textsf{TM}}.\textsf{Enc}$ algorithm on input $\bar{v}_w = \textsf{bid}+w$, except that they do not include the $\rho _{\gamma _w}$ component; this is added during the $\textsf{Tally}$ protocol. We call values $\bar{v}_w \in \mathbb {Z}_{q}$ the extended votes and values $v_w := \bar{v}_w \bmod {\alpha } \in [\alpha ]$ the raw votes. The randomnesses $r_w$ used in creating encryption $c_w$ are kept secret and placed under a detachable scratch surface on the ballot.

Both halves feature a designated gray area at the top. During the $\textsf{Cast}$ protocol, the BMD prints the voter-selected w in this gray area on both halves. Additionally, the right half includes a polling booth identifier j for the designated polling booth of the ballot, while the left half contains its commitment $\gamma _{\textsf{booth}} = g^{j}h^{r_{\textsf{booth}}}$. Randomness $r_{\textsf{booth}} \xleftarrow {\$} \mathbb {Z}_{q}$ is also put under a separate scratch surface. The commitment $\gamma _{\textsf{booth}}$ is revealed when the polling booth of a disputed VVPR needs to be identified in the $\textsf{TallyAudit}$ protocol.

Due to the size of encryptions $c_w$ (around 20 KB each [2]), they may not fit within standard QR codes on the paper ballot. However, conceptually, the actual encryptions could be stored in a backend server, with only a binding hash printed on the ballot. For simplicity, we ignore this complication.

Ballot Generation. During the $\textsf{BallotGen}$ protocol, a ballot is jointly generated by $\mathcal {G}_{1}$ and $\mathcal {G}_{2}$ to hide the voter-vote association from any one of them (see Fig. 4). $\mathcal {G}_{1}$, who selects the ballot secrets, does not learn the encryptions printed on the receipt half and cannot match voters to their ballot secrets, while $\mathcal {G}_{2}$, who creates the receipt half, does not know the ballot secrets.

$\mathcal {G}_{2}$ knows the destination booth j but keeps it hidden from $\mathcal {G}_{1}$ to hide booth-level voting statistics. It generates a commitment $\gamma _{\textsf{booth}}$ for j and shares it with $\mathcal {G}_{1}$ (lines 1–2), who prints it on the left half of the ballot. $\mathcal {G}_{1}$ generates a secret ballot identifier $\textsf{bid}$ and signs it (lines 2–3), computes $\bar{v}_w = \textsf{bid}+w$ for each w and accordingly prints candidate names on the left half and randomnesses $r_w$ under a scratch surface on the right half (lines 6,10). It then sends the partially printed ballot to $\mathcal {G}_{2}$, keeping the left half hidden. This can be done, e.g., by folding the ballot along the perforation line, sealing it and letting $\mathcal {G}_{2}$ print its contents on the back side of the right half. It also sends encryptions of each $\bar{v}_w$ under $\varPi _{\textsf{TM}}.\textsf{Enc}$, except the $\rho _{\gamma _w}$ components, to $\mathcal {G}_{2}$ (lines 7–9,12).

$\mathcal {G}_{2}$ re-randomises the obtained commitments/encryptions and homomorphically computes fresh shares of $\bar{v}_w$ and the commitment randomnesses using the additive homomorphism of $\textsf{E}$ in $\mathbb {Z}_{q}$ (lines 13–19). It then prints these re-randomised encryptions on the right half of the received ballot and signs them. The re-randomisation ensures that $\mathcal {G}_{1}$ cannot identify the ballot corresponding to a voter from their receipt. The commitment randomness $r_{\textsf{booth}}$ of $\gamma _{\textsf{booth}}$ is printed on another scratch surface on the right half.

Fig. 4.

The $\textsf{BallotGen}$ protocol for generating a ballot for booth j known only to $\mathcal {G}_{2}$.

Vote Casting. The $\textsf{Cast}$ protocol for voter $\mathcal {V}_{i}$ at booth j is as follows (Fig. 3 - center):

• Ballot pick-up and eligibility verification: $\mathcal {V}_{i}$ picks up a random sealed ballot from a set of ballots kept at the polling booth. The polling officer $\mathcal {P}_{j}$ verifies $\mathcal {V}_{i}$’s eligibility in the presence of polling agents and allows $\mathcal {V}_{i}$ to proceed to a private room containing a BMD $\mathcal {D}_{j}$.

• Vote casting: $\mathcal {V}_{i}$ feeds the top gray region of the ballot to $\mathcal {D}_{j}$ and presses a button on the onscreen display to select w corresponding to her preferred candidate. We denote the voter’s chosen w as $\dot{w}$. $\mathcal {D}_{j}$ can only access the top gray region for printing and cannot read any part of the ballot (it should not have any attached scanner or camera). $\mathcal {D}_{j}$ prints $\dot{w}$ on both the left and the right halves of this gray region. $\mathcal {V}_{i}$ needs to verify that indeed her intended choice is printed on both the halves. If satisfied, $\mathcal {V}_{i}$ separates the left half of the marked ballot (the VVPR), folds it and drops it into a physical ballot box $\mathcal {B}_{j}$ kept near $\mathcal {P}_{j}$ such that $\mathcal {P}_{j}$ can verify that the voter dropped an official VVPR. The right half (the receipt) is given to $\mathcal {P}_{j}$ for scanning. If not satisfied, $\mathcal {V}_{i}$ shreds the marked ballot and raises a dispute. In this case, $\mathcal {V}_{i}$ is allowed to re-vote. Note that the vote casting phase can also completely avoid the BMD and require the voter to hand-mark the two ballot halves, but this design is prone to more voter errors (see Sect. 2).

• Receipt scanning: $\mathcal {P}_{j}$ checks that the scratch surface on $\mathcal {V}_{i}$’s receipt is intact, i.e., the ballot secrets are not compromised, and shreds the scratch region in front of $\mathcal {V}_{i}$. From the scanned receipt, $\mathcal {P}_{j}$ extracts $c_{\dot{w}}$ and uploads $(\textsf{vid}_i, j, c_{\dot{w}})$ to $C$, along with $\sigma _{\textsf{vid}_i} \leftarrow \varPi _{\textsf{S}}.\textsf{Sign}(\textsf{sk}_{\mathcal {P}_{j}}, (\textsf{vid}_i, j, c_{\dot{w}}))$. $\mathcal {P}_{j}$ also affixes $\textsf{vid}_i$ to $\mathcal {V}_{i}$’s receipt, stamps it for authenticity, and returns it to $\mathcal {V}_{i}$.

Chain Voting and Randomisation Attacks. With minor modifications, these sophisticated coercion attacks can also be handled. For chain voting, $\mathcal {P}_{j}$ can stamp a serial number on the receipt half of the sealed ballot after identity verification to prevent the use of rogue ballots. This number is matched before accepting the voter’s receipt. Under a randomisation attack, voters may be asked to choose a fixed $\dot{w}$, thereby randomising their votes. To counter this, voters should be allowed to choose their ballots in a private room. The ballot cover should contain a detachable slip showing the candidate order, allowing coerced voters to choose a ballot so that they can vote for their preferred candidate while producing the $\dot{w}$ satisfying the coercer. Before proceeding to $\mathcal {P}_{j}$, the voter should detach the slip.

Vote Tallying. Post polling, $(\mathcal {M}_{k})_{k \in [m]}$ process the tuples $\{(\textsf{vid}_i, j_i, c_{i})\}_{i=0}^{n-1}$ uploaded on $C$ by $(\mathcal {P}_{j})_{j\in [\ell ]}$, where $c_i$ denotes $c_{\dot{w}}$ for the $i^{\text {th}}$ voter (Fig. 3 - right). $(\mathcal {M}_{k})_{k \in [m]}$ proceed as per Fig. 5 where they first add the ${\rho _{\gamma }}_i$ components to the encryptions $c_{i}$ by engaging in a distributed NIZK proof of knowledge (lines 2–9) and then processing $({c}_{i})_{i \in [n]}$ through the traceable mixnet’s $\textsf{Mix}$ protocol (line 13). At the end, the permuted extended votes $({\bar{v}}_{i}')_{i \in [n]}$ are obtained from which the raw votes are computed (line 14). Both extended and raw votes are published on $V$.

The VVPRs from each polling booth’s ballot box are collected and mixed in a central facility. VVPRs are revealed to the public only after this mixing phase and post audit, to avoid leaking polling booth-level voting statistics. A VVPR containing ballot identifier $\textsf{bid}$ and voter choice $\dot{w}$ can be matched with the corresponding decrypted vote by computing $\textsf{bid}+\dot{w}$, finding it on $V$ and checking if the corresponding raw vote matches the candidate name printed on the $\dot{w}^{\text {th}}$ row on the VVPR.

Fig. 5.

The $\textsf{Tally}$ protocol involving $(\mathcal {M}_{k})_{k \in [m]}$ on input $\textsf{mpk}, ({c}_{i})_{i \in [n]}$ and $\mathcal {M}_{k}$’s input ${\textsf{msk}}^{(k)}$ containing $\textsf{sk}_{\mathcal {M}_{k}}$.

Ballot and Receipt Audits. In the $\textsf{BallotAudit}$ protocol, a statistically significant number of ballots at each polling booth must be audited to keep the probability $\epsilon _{\textsf{b}}$ of a cast-as-intended failure (see Sect. 3) small. Ballot audits can happen before, during or after polling, and even be initiated by voters. When auditing a ballot, its sealed cover is opened and secrets under its scratch surfaces are revealed. For each $w = 0 \dots \alpha -1$, it is checked that encryption $c_w$ is created correctly on message $\textsf{bid}+w$ using $r_w$ and the candidate name printed at row w is $\textsf{cand}_{\textsf{bid}+w \bmod {\alpha }}$, where $\textsf{bid}$ is looked up from the left half and $r_w$ from the scratch surface. Further, it is checked that $\gamma _{\textsf{booth}}{\mathop {=}\limits ^{?}}g_1^{j}h_1^{r_{\textsf{booth}}}$, where j is the audited booth’s identifier and $r_{\textsf{booth}}$ is obtained from the scratch surface, and that signatures by $\mathcal {G}_{1}, \mathcal {G}_{2}$ verify. Since the secrets of audited ballots are revealed, audited ballots cannot be used for vote casting and must be spoiled.

Similarly, in the $\textsf{ReceiptAudit}$ protocol, a statistically significant number of voter receipts from each polling booth must be checked for their existence on list $C$ to keep $\epsilon _{\textsf{r}}$ small. All audited receipts should be uploaded to $R$ to aid audit and recovery.

Tally Audit. Our tally audit protocol (see Fig. 6) depends on BTraceIn and BTraceOut queries of a traceable mixnet (see Sect. 4.1). Given (R, C, V, P), first, all input-phase failures are marked (lines 1–3). Here, as per the discussion in Sect. 2, we mark all receipts/encrypted votes from a booth as failed if any one of them fails and the encrypted votes as failed if the ballot audit at that booth failed. For marking mixing phase failures on $C$ and $V$, we run the BTraceIn/BTraceOut queries against the complete set of entries on $V$ and $C$ respectively (lines 4–5). Output-phase failures are marked by comparing the VVPRs with the decrypted extended votes (lines 6–7).

If the total number of failures is less than the winning margin, then $J^* = \emptyset$ and $V^*=V$ are reported, signalling that no rerun is required (lines 9–10). Otherwise, polling booths contributing all the failing items are identified: for receipts and encrypted votes, the booth identifiers directly exist on $R$ and $C$ (line 12); for VVPRs without an electronic entry, they are identified by asking $\mathcal {G}_{2}$ to open the opening of $\gamma _{\textsf{booth}}$ printed on the VVPR (line 13); for decrypted votes, a $\textsf{BTraceOut}$ query against the set of ciphertexts cast at a booth j is run for all booths $j \in [\ell ]$ (lines 14–18). The set of all such booths is reported in $J^*$ (line 19). The decrypted votes $V^*$ contributed by the good booths are obtained by running another $\textsf{BTraceOut}$ query against the entries on $C$ contributed by booths outside of $J^*$ (line 21).

Fig. 6.

The $\textsf{TallyAudit}$ protocol involving $\mathcal {A}$, $(\mathcal {M}_{k})_{k \in [m]}$ and $\mathcal {G}_{2}$ with public input (R, C, V, P), each $\mathcal {M}_{k}$’s input its mixnet secret key ${\textsf{msk}}^{(k)}$ and witness ${\omega }^{(k)}$ output by the traceable mixnet during the $\textsf{Tally}$ protocol, and $\mathcal {G}_{2}$’s input being $(j,r_{\textsf{booth}})$ stored indexed by $\gamma _{\textsf{booth}}$ at the end of the $\textsf{BallotGen}$ protocol.

Recovery. The suggested recovery is to rerun the election only on booths in $J^*$ and later merge this tally with the tally reported in $V^*$. However, if $J^*$ is small, one can also consider rerunning on a few randomly selected good booths too, to avoid specialised targeting of the booths in $J^*$. Further, the general approach of TraceIn/TraceOut queries can also support other recovery options for dual voting systems. For example, one can immediately recover from case $\textsf{FO}_3$ if a TraceOut query is run for the decrypted vote against the set of encrypted votes that successfully matched with voter receipts. If the answer is yes, then it provides solid evidence that the VVPR is wrong, without leaking any additional information. A similar query run for the VVPR provides solid evidence that the electronic vote was wrong. Of course, what queries to allow must be carefully decided depending on the situation to best optimise the recoverability-secrecy tradeoff.

5 Security Analysis

Theorem 1

Under the DL assumption in $\mathbb {G}_{1}$, the n-SDH assumption in $(\mathbb {G}_{1}, \mathbb {G}_{2})$ [7] and the EUF-CMA security of $\varPi _{\textsf{S}}$, the OpenVoting protocol is recoverable as per Definition 1.

Proof (Sketch)

We focus on the event that for each booth, $\textsf{BallotAudit}$ passing implies that all receipts correctly captured voter intents and $\textsf{ReceiptAudit}$ passing implies that all receipts were correctly uploaded. This event happens with probability $1-\ell (\epsilon _{\textsf{b}}+\epsilon _{\textsf{r}})$.

Let $J^*,V^*$ be $\mathcal {A}$’s output in the $\textsf{TallyAudit}$ protocol. From Fig. 6, we consider the two cases: first when the branch on line 8 is taken and the second when it is not taken. In the first case, $J^* = \emptyset$ and thus we must show that the number of failures in $(R^*,C^*,V^*,P^*)$ is less than the winning margin, where $R^*=R$, $C^*=C$ and $P^*=P$ for $J^*= \emptyset$ and $V^* = V$ by line 10. By the condition on line 9, the number of reported failures is less than the winning margin. By the soundness of $\varPi _{\textsf{TM}}$ under the stated assumptions [2], sets ${C}_{\text {FM}}$ and ${V}_{\text {FM}}$ correctly represent the set of true failures. This, combined with the definitions of ${R}_{\text {FI}}$, ${C}_{\text {FI}}$, ${V}_{\text {FO}}$ and ${P}_{\text {FO}}$, implies that the number of real failures in $(R^*,C^*,V^*,P^*)$ is less than the winning margin.

In the second case, $J^*$ is, as required, exactly the non-empty set of booths that contributed some failing item in $R_{\text {F}}$, $C_{\text {F}}$ (by the definitions on line 12), $P_{\text {F}}$ (by line 13 and the computational binding of Pedersen commitments under the DL assumption in $\mathbb {G}_{1}$) or $V_{\text {FO}}$ (by lines 14–18 and the soundness property of $\varPi _{\textsf{TM}}$; note that $V_{\text {FM}}$ entries in $V_{\text {F}}$ are mix-server errors and, as required, are not reported here). Finally, by line 21 and the soundness of $\varPi _{\textsf{TM}}$, $V^*$ is exactly the set of votes decrypted from encrypted votes sent by booths outside $J^*$. Thus, by the definitions of $R^*$, $C^*$ and $P^*$, $(R^*,C^*,V^*,P^*)$ does not contain any failures.

Theorem 2

Under the DDH assumption in $\mathbb {G}_{1}$ and the DCR assumption [19], the OpenVoting protocol satisfies vote secrecy with recoverability as per Definition 2 in the random oracle model.

Proof (Sketch)

If the adversary corrupts $\mathcal {G}_{2}$ but not $\mathcal {G}_{1}$, then it does not learn the ballot secrets of ballots used by $\mathcal {V}_{i_0}$ and $\mathcal {V}_{i_1}$ by the perfect hiding of Pedersen commitments under the DDH assumption and the IND-CPA security of Paillier schemes $\textsf{E}$ and $\textsf{E}_{\textsf{Pa}}^{\textsf{th}}$ under the DCR assumption (see Fig. 4). Post-printing, ballots get sealed and are opened only by the voter during vote casting, where the adversary-controlled BMD does not see any information about the ballot used. The receipts and the tallying protocol does not reveal any information to the corrupted mix-servers by the secrecy property of $\varPi _{\textsf{TM}}$ under the stated assumptions [2]. VVPRs are collected after mixing and the ballot identifiers used therein cannot be linked to the identifiers of $\mathcal {V}_{i_0}$ and $\mathcal {V}_{i_1}$. Finally, during the $\textsf{TallyAudit}$ protocol, it is required that if the adversary causes a failure in either the receipt, encrypted vote or VVPR contributed by $\mathcal {V}_{i_0}$’s booth $j_0$ then it should also cause a failure in $\mathcal {V}_{i_1}$’s booth $j_1$. Thus, sets $R_{\text {FI}}$ to $P_{{\textsf{FO}}}$ in Fig. 6 do not help it distinguish between the two worlds. Outputs $V_{\text {F}_j}$ do not help because for each failure in booth $j_0$, the adversary is required to create an identical failure in booth $j_1$. Further, the partial tally $V^*$ includes either both $v_0,v_1$ or none of them. The secrecy property of $\varPi _{\textsf{TM}}$ ensures that no additional information beyond the query outputs is revealed.

If the adversary corrupts $\mathcal {G}_{1}$ but not $\mathcal {G}_{2}$, then it obtains ballot secrets but it cannot identify which of $\mathcal {V}_{i_0}$ or $\mathcal {V}_{i_1}$ used which ballot. The rest of the proof is similar.

6 Conclusion and Future Work

We have introduced and formalised the notion of recoverability and secrecy for dual voting protocols and suggested a protocol that achieves this notion. Based on existing reports for the underlying traceable mixnet construction, the total time taken by the recovery process remains within a few hours for $n=10000$ ciphertexts, which can be optimised further using the construction’s high degree of task parallelism [2].

Although we have shown our protocol’s recoverability properties, the potential non-termination of the revoting process during vote casting seems like an inherent limitation of BMD protocols and designing voting frontends that overcome this limitation yet remain usable and minimise voter errors appears to be a challenging open problem. Further, although we have focused on recoverability for first-past-the-post voting where exact winning margins are computable, extending to other more complex voting rules also appears to be an interesting avenue for future work.