1 Introduction

Internet voting has been used by many institutions, such as companies, universities or non-governmental organisations, as well as for some remote national elections. The adoption of Internet voting has been driven by several practical advantages of this form of voting, in particular the possibility for all voters to participate regardless of their physical location.

However, Internet voting has its own challenges and risks. One of these risks is the potential for malfunction, which cannot be easily excluded in such complex software/hardware systems. Such problems can be caused by design/programming errors, security vulnerabilities or even deliberate manipulation of the deployed system. In any case, malfunctions can have potentially serious practical consequences. If the final result of an election is accepted even though it does not correspond to the votes cast by the voters, the very purpose of the election is undermined.

To protect against such risks, modern Internet voting systems strive for so-called end-to-end verifiability [8]. This fundamental property requires the system to provide evidence that the election result accurately reflects the votes cast by eligible voters. Importantly, this evidence must be independently verifiable.

Individual verifiability is an essential part of end-to-end verifiability. This property guarantees that each individual voter is able to verify that the vote she has cast on her voting machine has actually been counted. Individual verifiability is typically achieved in the following way. First, the voter checks whether her (possibly malfunctioning) voting machine has cast her encrypted vote as she intended; this property is called cast-as-intended verifiability. Then the voter checks that the vote she cast is recorded by the authorities; this feature is called recorded-as-cast. These features, when combined with universal verifiability (providing tallied-as-recorded), allow all individual voters to independently verify that their exact secret votes are counted.

The requirement for end-to-end verifiability in general, and individual verifiability in particular, is not only widely accepted by the research community, but is also becoming part of standard legal requirements and frameworks. The importance of verifiability is, for example, recognised by the Council of Europe in its Recommendation on standards for e-voting [26]. Importantly, the same document specifies that “individual verifiability can be implemented provided adequate safeguards exist to prevent coercion or vote-buying”. Requirements for individual verifiability are also postulated for the Swiss elections in Federal Chancellery Ordinance on Electronic Voting, for the Estonian elections in Riigikogu Election Act, and for non-political elections in Germany [5].

Numerous techniques for cast-as-intended verifiability have been proposed in the literature (see, e.g., [2, 4, 7, 11,12,13,14,15, 18, 22, 27]). Some of them are also employed in real elections, for example [10, 18] in the Estonian voting system IVXV, and [2] in the Helios voting system [1]. Each of these techniques provides its own balance between security, trust assumptions, usability, and deployability.

Our Contributions. We propose a method for cast-as-intended verifiability (called CAISEDFootnote 1) that offers a new balance between security guarantees and practicality; in particular, it can be used to augment many relevant Internet voting protocols. Our method does not increase the risk of vote selling, when compared to the underlying voting protocol being augmented, which is provided under comparatively weak trust assumptions.

The method proposed in this paper is intended to be an optional feature of the POLYAS 3.0 e-voting platform to ensure cast-as-intended verifiability. Our design choices have therefore been informed by practical considerations and the needs of a wide range of customers and use cases.

More specifically, we have optimised our cast-as-intended mechanism for the following design goals. The first four design goals, (DG1)–(DG4), are functional and essentially determine the election scenarios in which the cast-as-intended mechanism can be used; in combination, the functional design goals cover a wide range of real-world elections over the Internet, which is a key requirement for our practice-oriented work. The last two design goals (DG5)–(DG6) express security features that the cast-as-intended mechanism should provide.

  • (DG1) Support for flexible ballot types. The mechanism should not be limited to certain types of ballots, such as simple ballots with a relatively small number of candidates or simple voting rules. On the contrary, it is desirable that complex ballots are supported, including, for example, ballots with write-in candidates or ranked ballots.

  • (DG2) Low cost. The mechanism should not significantly increase the cost of the election, for example by requiring special secure printing/distribution facilities.

  • (DG3) No disenfranchisement of voters. The mechanism should not make unrealistic assumptions about voters’ knowledge, skills, and possessions. This rules out mechanisms that require some kind of special hardware. It should also be reasonably intuitive, so that an average voter can understand what to do and why.

  • (DG4) Modularity. The mechanism can be used to augment a large class of Internet voting protocols, in particular protocols using different types of tallying, and protocols with everlasting privacy. The method should support modular security analysis, where the security properties of the combined scheme can be derived from the security properties of the underlying protocol (without individual verifiability) and the properties of the individual verifiability method.

  • (DG5) No facilitation of vote-selling. The mechanism should not make it easier to sell votes than in the voting scheme being extended. To be clear, we do not aim to protect the entire voting scheme against vote selling, but we do require that the cast-as-intended mechanism should not additionally provide voters with receipts that they can use to trivially prove to a vote buyer how they voted.

  • (DG6) Possibly minimal trust assumptions. We prioritise solutions that require weaker or more flexible trust assumptions. An example of a trust assumption we want to avoid is relying on some trapdoor values generated by a trusted party, where for the integrity of the individual verifiability method we need to assume that this party is honest (not corrupted) and that the trapdoor value does not leak.

As we discuss in detail in Sect. 2, no existing cast-as-intended verifiability method in the literature satisfies all of our design goals simultaneously. We note, however, that while our solution is optimised for our particular design goals, other methods may be better suited for different election settings that require a different resolution of the security/usability/deployability trade-offs.

Let us now explain at a high level how and why our cast-as-intended mechanism achieves all of our design goals satisfactorily:

  • We follow the approach of using a second device, called an audit device, which allows voters to verify that the digital ballot submitted on their behalf contains their intended choice. This approach is well established and has already been used in real elections, for example in Estonia [18]. More specifically, in our method, the voter can use a common device, such as a mobile phone or tablet, as an audit device. This audit device needs to be able to scan QR codes, and it also needs to be connected to the internet in order to communicate with the voting system. This way we avoid costly additional infrastructure (DG2) and we do not have to make unrealistic assumptions about what voters have (DG3).

  • From the voter’s point of view, the audit process is straightforward, as explained next. Once the encrypted ballot has been sent to the voting system, the voting application displays a QR code. The voter uses the audit device to scan this QR code. The audit device then prompts the voter to authenticate to the election system and, if this authentication is successful, displays the voter’s choice in clear text, in the same form as the ballot was displayed on the primary (voting) device. We note that most voters today are used to this or similar checks, for example in the context of secure online banking. Furthermore, the verification step is optional and thus not required for a successful vote. In summary, we make reasonable assumptions about voters’ knowledge and skills (DG2).

  • On a technical note, our method works well with all possible ballot types, even very complex ones, satisfying (DG1). Moreover, our modular method can be used to augment a large class of relevant Internet voting protocols (DG4), and the computational cost of the ballot auditing computations is very reasonable (DG2).

  • Unlike all previous cast-as-intended mechanisms that employ a second device [13, 18], our method simultaneously satisfies (DG5) and (DG6). We achieve this by providing cryptographic deniability, without introducing additional trust assumptions. To do this, we employ interactive zero-knowledge proofs where, by definition, any party can easily simulate the protocol transcript without knowing the plaintext or the encryption coin. We use well-understood and relatively simple cryptography: our method is essentially based on the interactive zero-knowledge proof of correct re-encryption. This results in simpler security proofs, which is another important factor in building trust.

Technically, the main challenge we had to overcome was caused by the general limitations of QR codes. As described above, the QR codes in our method are used as the only communication channel between the voting application and the audit device. However, QR codes provide very limited communication capacity as they are one-way and have very limited bandwidth. In order to implement an interactive zero-knowledge proof in this restricted setting, we split the role of the prover between the voting application and the voting system in such a way that the voting system does not learn anything during the process, while it does most of the ‘heavy lifting’. The role of verifier, as usual in such schemes, is played by the second device.

We note that, since the audit device displays the voter’s choice, it must be trusted for ballot privacy. This is also the case for all other techniques that deploy a second device [13, 18]. In general, cast-as-intended methods based on return or voting codes do not have this disadvantage, but they do fall short of other design goals (see Sect. 2 for more details).

Structure of the Paper. In the next section, we provide more details on the existing approaches for cast-as-intended verifiability. We describe our cast-as-intended mechanism in Sect. 3 and we analyze its security in Sect. 4. In Sect. 5, we embed our cast-as-intended protocol in an example protocol which provides full individual verifiability and state higher-level security properties of this protocol. Finally, in Sect. 6, we discuss some practical cryptographic instantiations of our approach. See the full version of this paper [25] for more details.

2 Related Work

Various mechanisms for individual (cast-as-intended) verifiability have been proposed in the literature, striking different balances between security, usability, and various other practical aspects of the voting process. In this section, we give a brief overview of such mechanisms and explain why none of them provide the security features (DG5)-(DG6) in the real-world elections we are interested in, as determined by (DG1)-(DG4). In particular, we focus here only on methods used for Internet e-voting as opposed to on-site voting).

Return Codes. In the return-codes-based approach (see, e.g., [4, 11, 14, 15]), before the voting phase starts, each voter receives a code sheet (e.g. via postal mail) listing all the possible voting choices together with corresponding verification codes. These codes are unique for each voter and should be kept secret. During the voting phase, the voter, after having cast her ballot, receives (via the voting application or another dedicated channel) the return code corresponding to the selected choice. The voter compares this code to the one listed on the code sheet next to the intended choice.

While this approach may work well and seems intuitive from the voter’s point of view, it has several drawbacks. It does not scale well to complex ballots (\(\lightning \)DG1), such as ballots with many candidates or when voters have the option to select multiple choices, because the code sheets become very big and the user experience quickly degrades (see, e.g., [21]). Another disadvantage is the cost incurred by (secure) printing and delivery of code sheets (\(\lightning \)DG2). Finally, the printing and delivery facilities must be trusted in this approach: if the verification codes leak to the adversary, the integrity of the process completely breaks (a dishonest voting client can cast a modified choice and return the code corresponding to the voter’s intended choices). This trust assumption is rather strong (\(\lightning \)DG6).

Voting Codes. In this approach, the voter, as above, obtains a voting sheet with voting codes. The difference is that the codes are not used to check the ballot after it has been cast, but instead to prepare/encode the ballot in the first place: in order to vote, the voter enters the code (or scans a QR-code) corresponding to their choice. By construction, the voting client is then only able to prepare a valid ballot for the selected choice and no other ones. This approach is used, for example, in [7], where the voting codes are used not only to provide individual verifiability, but also to protect ballot privacy against dishonest voting client.

This approach, similarly to the return codes, works only for simple ballots (\(\lightning \)DG1); arguably, the usability issues are even bigger than for return codes, as the voter needs to type appropriated codes or scan appropriate QR-codes in order to correctly cast a ballot, not just compare the returned code with the expected one. As before, it incurs additional costs (\(\lightning \)DG2) and requires one to trust the printing/delivery facilities (\(\lightning \)DG6).

Cast-or-Audit. The cast-or-audit approach, used for instance in Helios [1], utilizes the so-called Benaloh Challenge [2] method. In this approach, the voter, after her choice has been encrypted by the voting client, has two options: she can either choose to (1) cast this encrypted ballot or (2) challenge (i.e., audit) the ballot. If the latter option is chosen, the voting client enables the audit by revealing the randomness used to encrypt the ballot, so that the voter (typically using some additional device or application) can check that it contains the intended choice. The voter then starts the ballot cast process over again, possibly selecting a different choice.

The security of this approach relies on the assumption that the client application (the adversary) does not know beforehand, whether the encrypted vote will be audited or cast. Therefore, if the adversary tries to manipulate the ballot, it risks that this will be detected. Note, however, that the ballot which is actually cast is not the one which is audited. This, unlike most of the other approaches, provides the voter with some (probabilistic) assurance, but not with fully effective guarantees.

This method has the advantage that it does not produce a receipt (the voter can choose different candidates for the audited ballots) and that the audit device does not need to have Internet access for verification (unlike cast-and-audit methods like ours), but it has several usability issues. The studies on usability of this scheme [19, 28] conclude that voters tend to not verify their votes and have serious problems with understanding the idea of this type of ballot audit, which make this approach score low on (DG3). The above issues render the cast-or-audit approach ineffective in practice.

Cast-and-Audit. The solution presented in this paper belongs to this category. In this approach, the voter audits, typically using a second device, the cast ballot (before or after it is cast). This approach is used by the system deployed for the Estonian elections [18]. In this case, the voters can use a mobile application to scan a QR-code displayed by the voting client application. This QR-code includes the random encryption coin used to encrypt the voter’s choice. The audit device fetches the voter’s ballot from the ballot box and uses the provided randomness to extract the voter’s choice which is then displayed for the voter to inspect.

This method is flexible as it works well also for complex ballot types (DG1) (the audit device conveniently displays the vote in the same way the ballot appeared in the main voting device). The user experience, for this method, is relatively simple (DG3). The method does not incur extra cost (DG2).

The main disadvantage of this method in general is that the additional (audit) device must be trusted for ballot privacy, as it “sees” the voter choice in clear. Also, the fact that the voters need to have an additional device (such as a mobile phone), which is able to scan QR-codes and which has Internet access, can be seen as a disadvantage. However, with the high availability of such devices, this does not seem to be a significant issue in practice. The correctness of the ballot audit process relies on the assumption that one of the devices the voter uses (either the main voting device or the audit device) is not corrupted. In practice, it is therefore desirable that the software programs (apps) run on these two devices were developed and installed independently, ideally by different vendors or trusted third parties (e.g., pro-democratic organizations).

The main idea of the cast-as-intended mechanism proposed in [18] is that the QR-code includes the encryption random coins. Such a coin constitutes a trivial and direct evidence for the plaintext content of the encrypted ballot. As such, the simple cast-as-intended mechanism of [18] does not provide cryptographic deniability and may potentially facilitate vote buying/coercion (\(\lightning \)DG4). Whether this potential for vote buying/coercion becomes an actual threat depends on the overall voting protocol; for instance, the Estonian system allows for vote updating as a measure to mitigate the threat of coercion. The lack of cryptographic deniability remains nevertheless a serious drawback of this method and significantly limits it applicability.

The issue of selling cast-as-intended data as trivial receipts in Internet elections is addressed in [13], where cryptographic deniability is provided using non-interactive zero-knowledge proofs with trapdoors. This solution to the receipt problem has, however, its own issues: the trapdoor (for each voter) is generated by a registrar who therefore needs to be trusted for integrity of this method. This is arguably a strong trust assumption (\(\lightning \)DG6).

As already mentioned in the introduction, the solution presented in this paper, while also providing cryptographic denialability, does not require such an additional trust assumption (DG6). It also avoids the relatively complex cryptographic machinery of [13], which often is the source of serious programming flaws (see, e.g., [16]).

Custom Hardware Tokens. Some other solutions, such as [12], rely on using dedicated hardware tokens during the cast process. Relying on custom hardware makes these solutions expensive and difficult to deploy in real, big scale elections (\(\lightning \)DG2), (\(\lightning \)DG3). Furthermore, [20] demonstrated that [12] suffers from several security issues and concluded that [12] was not yet ready to be deployed.

Tracking Codes. The sElect system [22] achieves cast-as-intended in a simple way: voters are given random tracking numbers as they cast their ballots. After the tally, voters can check that their tracking numbers appear next to their respective votes.

This method is simple and intuitive for the voters, but has the following drawbacks. End-to-end verifiability relies on the voters to perform the checks because there is no universal verifiability process that complements the individual verifiability made by the voters. Also, in [22], the tracking codes were “generated” and entered by the voters. This is somehow problematic both from the usability point of view and because of the poor quality of “random” numbers made up by voters (see, e.g., [3]). Altogether, this method seems to take somehow unrealistic assumptions about the voters: that the voters carry out the process often enough for achieving the desired security level and that they are able to generate decent randomness (\(\lightning \)DG3). Furthermore, the tracking codes, as used in [22], may allow for simple vote buying (\(\lightning \)DG5).

The construction presented in Selene [27] also builds upon the idea of tracking codes, but further guarantees receipt-freeness, and thus impedes vote buying, due to a complex cryptographic machinery. The cast-as-intended mechanism is here, however, tightly bound to the e-voting protocol and thus not modular (\(\lightning \)DG4). In particular, unlike for the method proposed in this paper, it is not immediately obvious how to improve Selene towards everlasting privacy or how to instantiate Selene with practical post-quantum primitives.

3 Cast-As-Intended Verifiability: Generic Protocol

In this section, we present our protocol for cast-as-intended verifiability. We take a modular approach: in Sect. 3.1, we first describe a generic basic ballot submission process without cast-as-intended, and then, in Sect. 3.2, we build on this basic process and extend it with cast-as-intended verifiability.

The protocol presented here, with the security result given in Sect. 4, deals only with the core cast-as-intended mechanism. In particular, it does not address the recorded-as-cast aspect of individual verifiability. In Sect. 5, we explain how to (easily) extend our cast-as-intended protocol to achieve full individual verifiability.

3.1 Basic Ballot Submission

We describe now how the basic ballot submission (sub-)protocol of an e-voting protocol without cast-as-intended verifiability works which establishes the starting point for our mechanism, introduced in the next subsection. Doing this, we abstract from some aspects (such as authentication) which are irrelevant for our cast-as-intended protocol.

We provide this explicitly defined basic protocol in order to be able to compare the knowledge the voting server gathers during this process with the knowledge it gathers during the process extended with the cast-as-intended mechanism.

Participants. The basic submission protocol is run among the following participants: the voter V, the voting device \( VD \), and the voting server \( VS \). In what follows, we implicitly assume that the channel from V (via the voting devices) to the voting server \( VS \) is authenticated without taking any assumption about how authentication is carried out.Footnote 2

Cryptographic Primitives. In the basic ballot submission protocol, an IND-CPA-secure public-key encryption scheme \(\mathcal {E}= (\textsf{KeyGen}, \textsf{Enc}, \textsf{Dec})\) is employed.

Ballot Submission (Basic). We assume that \((pk, sk) \leftarrow \textsf{KeyGen}\) was generated correctly in the setup phase of the voting protocol and that each party knows pk.Footnote 3 The program of the basic submission protocol works in the standard way:

  1. 1.

    Voter V enters plaintext vote v to her voting device \( VD \).

  2. 2.

    Voting device \( VD \) chooses randomness \(r \xleftarrow {\$} R\), computes ciphertext \(c \leftarrow \textsf{Enc}(pk, v; r)\), and sends c to voting server VS.

We note that the basic protocol may include signing the ballot with voter’s private key if a public-key infrastructure (PKI) among the voters is established.Footnote 4

3.2 Cast-as-Intended Verifiable Ballot Submission

We now describe how to extend the basic ballot submission protocol described above for cast-as-intended verifiability.

Participants. In addition to the three participants of the basic ballot submission phase (voter V, voting device \( VD \), voting server \( VS \)), the extended protocol also includes an audit device \( AD \).

Cryptographic Primitives. The extended submission protocol employs the following cryptographic primitives:

  1. 1.

    An IND-CPA-secure public-key encryption scheme \(\mathcal {E}= (\textsf{KeyGen}, \textsf{Enc},\textsf{Dec})\) that allows for re-randomization and special decryption:

    • Re-randomization guarantees the existence of a probabilistic polynomial-time (ppt) algorithm \(\textsf{ReRand}\) which takes as input a public key pk together with a ciphertext \(c = \textsf{Enc}(pk, m; r)\) and returns a ciphertext \(c^*\) such that \(c^* = \textsf{Enc}(pk, m; r^*)\) for some (fresh) randomness \(r^*\). We assume that \(\textsf{ReRand}\) is homomorphic w.r.t. randomness: \( \textsf{Enc}(pk, m; x + r) = \textsf{ReRand}(pk, \textsf{Enc}(pk, m; r); x). \)

    • Special decryption guarantees the existence of a polynomial-time (pt) algorithm \(\textsf{Dec}'\) which takes as input a public key pk, a ciphertext c, and a randomness r, and returns the plaintext m, if \(c = \textsf{Enc}(pk, m; r)\), or fails otherwise.Footnote 5

    Note that neither \(\textsf{ReRand}\) nor \(\textsf{Dec}'\) require knowledge of the secret key sk associated to pk. Example cryptosystem which provide these operations are the standard ElGamal encryption (see Sect. 6) and commitment consistent encryption [9].

  2. 2.

    A proof of correct re-encryption, i.e., an interactive zero-knowledge proof (ZKP) \(\pi _{\textsf{ReRand}}\) for the following relation: \( (pk, c, c^*; x) \in \mathcal {R}_{\textsf{ReRand}} \Leftrightarrow c^* = \textsf{ReRand}(pk, c; x). \) The joint input of the prover and the verifier is statement \((pk, c, c^*)\) and the secret input of the prover is witness x, i.e., the randomness used to re-randomize ciphertext c into \(c^*\).

Ballot Submission (Extended). The program of the extended ballot submission works as follows (note that the first two steps are the ones of the basic ballot submission protocol):

  1. (BS1)

    Voter V enters plaintext vote v to voting device \( VD \).

  2. (BS2)

    Voting device \( VD \) chooses randomness \(r \xleftarrow {\$} R\), computes ciphertext \(c \leftarrow \textsf{Enc}(pk, v; r)\), and sends c to voting server \( VS \).

  3. (BS3)

    Voting server \( VS \) chooses a blinding factor \(x \xleftarrow {\$} R\) and sends x to \( VD \).

  4. (BS4)

    Voting device \( VD \) computes blinded randomness \(r^* \leftarrow x + r\) and returns \(r^*\) to voter V (in the practical implementations, \(r^*\) can be displayed as a QR-code).

From the voter’s perspective, the outcome of the submission protocol consists of the blinded randomness \(r^*\), which is used for individual verification purposes, as described next.

Cast-as-Intended Verification. The program of the voter’s individual cast-as-intended verification works as follows. It is executed, if the voter chooses to audit his/her ballot. As for the ballot submission, in what follows, we implicitly assume that the channel from V (via the audit devices) to the voting server VS is authenticated.

  1. (BA1)

    Voter V enters \(r^*\) to the audit device AD (in practical implementations this is done by scanning a QR code produced by \( VD \)), which contacts voting server \( VS \).

  2. (BA2)

    Voting server \( VS \) computes ciphertext \(c^* \leftarrow \textsf{ReRand}(pk, c; x)\) (i.e., the original ciphertext c re-randomized with the blinding factor x) and sends the original ciphertext c along with \(c^*\) to the audit device AD.

  3. (BA3)

    Voting server \( VS \) and audit device \( AD \) run an interactive zero-knowledge proof \(\pi _{\textsf{ReRand}}\), where \( VS \) is the prover and \( AD \) the verifier, with joint input \((pk, c, c^*)\) and voting server’s secret input x in order to prove/verify that \(c^*\) is a re-randomization of c.

  4. (BA4)

    If the verification algorithm in the step above returned 1, then \( AD \) decrypts the re-randomized ciphertext \(c^*\) using blinded randomness \(r^*\) to obtain \(v^* \leftarrow \textsf{Dec}'(pk, c^*, r^*)\) and returns \(v^*\) to voter V. Otherwise, \( AD \) returns 0 (indicating failure) to V.

  5. (BA5)

    Voter V returns 1 (accepts) if AD returned \(v^*\) such that \(v = v^*\) (where v is the voter’s intended choice). Otherwise, V returns 0 (reject).

4 Security

Our cryptographic security analysis of the cast-as-intended protocol (as introduced in Sect. 3.2) consists of two parts. In the first part, we prove that this protocol is an interactive zero-knowledge proof (ZKP) protocol, run between voter V and audit device \( AD \), jointly playing the role of the verifier on the one side, and the voting device \( VD \) and voting server \( VS \) jointly playing the role of the prover on the other side. This fact establishes the cryptographic deniability of our cast-as-intended method: the protocol transcript (the data gathered by the audit device) is useless as a receipt, because an indistinguishable transcript can be generated by any party, using the simulator algorithm (for an arbitrary election choice, independently of the actual voter’s choice).

In the second part, we prove that the voting server \( VS \) does not learn more information about the voter’s secret choice than what \( VS \) already learns in the basic ballot submission protocol. Note that this statement is not directly covered by the zero-knowledge (simulation) property of the protocol, because \( VS \) is part of the prover.

In Sect. 5, we will explain how to extend the cast-as-intended protocol analyzed in this section so that it provides full individual verifiability.

4.1 Zero-Knowledge Proof

We now show that our cast-as-intended protocol is an interactive ZKP proving that a given ballot contains a vote for a particular candidate. From the soundness of this ZKP, it follows that even if the voter’s voting device \( VD \) and the voting server \( VS \) collude, then they are not able to convince the voter V (who uses an honest audit device \( AD \)) that her submitted ballot contains a vote for her favorite choice v when it actually contains a different choice. Moreover, due to the zero-knowledge property, \( VD \) and \( VS \) prove that the submitted ballot contains a vote for the voter’s favorite choice without revealing any information beyond this statement; in particular, the protocol does not leave any information which could undesirably serve as a receipt that could be used for vote buying.

Let \(\textsf{Verify}\) be the composition of the programs run by voter V and her audit device \( AD \) after the basic ballot submission protocol is completed, i.e., steps (BS3)–(BS4) in the extended ballot submission protocol followed by the cast-as-intended protocol; in short: \(\textsf{Verify}= (V \Vert AD )\). Analogously, let \(\textsf{Prove}\) be the unification of the programs run by the voting device \( VD \) and the voting server VS after the basic ballot submission protocol is completed; in short \(\textsf{Prove}= ( VD \Vert VS)\).

Observe that the resulting interactive protocol with joint input (pk, v, c) and prover’s secret input r can be re-written as the following protocol:

  1. 1.

    \(\textsf{Prove}\) chooses \(x \xleftarrow {\$} R\), computes \(r^* \leftarrow x + r\) and \(c^* \leftarrow \textsf{ReRand}(pk, c; x)\), and returns \((r^*, c^*)\).

  2. 2.

    \(\textsf{Prove}\) and \(\textsf{Verify}\) run the interactive ZKP \(\pi _{\textsf{ReRand}}\) with joint input \((pk, c, c^*)\) and prover’s secret input x.

  3. 3.

    \(\textsf{Verify}\) returns 1 if and only if the execution of \(\pi _{\textsf{ReRand}}\) returned 1 and \(v = \textsf{Dec}'(pk, c^*, r^*)\) holds true.

We now state that this protocol is an interactive ZKP for proving that ciphertext c encrypts vote v.

Theorem 1

The interactive protocol \(\pi _{\textsf{Enc}} = (\textsf{Verify}, \textsf{Prove})\) is a zero-knowledge proof for relation \(\mathcal {R}_{\textsf{Enc}}\) defined by the equivalence \((pk, v, c; r) \in \mathcal {R}_{\textsf{Enc}} \Leftrightarrow c = \textsf{Enc}(pk, v; r).\)

In order to prove this theorem, we need to show that \(\pi _{\textsf{Enc}}\) satisfies completeness (i.e., if \(\textsf{Verify}\) and \(\textsf{Prove}\) are executed correctly for a true statement, then \(\textsf{Verify}\) returns 1 with overwhelming probability), soundness (i.e., if \(\textsf{Verify}\) returns 1, then the statement is correct, even when interacting with a dishonest prover), and zero-knowledge (i.e., the verifier’s view can be simulated without knowledge of the witness), each with at least overwhelming probability.

Proof

Completeness: Let \(x, r^*, c^*\) be defined as in \(\textsf{Prove}\). Because \((pk, c^*, c; x) \in \mathcal {R}_{\textsf{ReRand}}\), the verifier returns 1 in an execution of \(\pi _\textsf{ReRand}\) with probability \(p_c\), where \(p_c\) is the correctness level of \(\pi _\textsf{ReRand}\). Furthermore, the verifier’s second check is also positive because

$$\begin{aligned} c^* = \textsf{ReRand}(pk, \textsf{Enc}(pk, v; r), x) = \textsf{Enc}(pk, v; x + r) = \textsf{Enc}(pk, v; r^*). \end{aligned}$$

Hence, \(\textsf{Verify}\) returns 1 in \(\pi _{\textsf{Enc}}\) with probability \(p_c\) if both \(\textsf{Verify}\) and \(\textsf{Prove}\) are executed correctly; in short: \(Pr[ \langle \textsf{Verify}, \textsf{Prove}(r) \rangle (pk, v, c) = 1 ] = p_c\).

Soundness: Assume that \(\textsf{Verify}\) returns 1. Then, due to the soundness of \(\pi _{\textsf{ReRand}}\), there exists with probability \(p_s\) a unique plaintext \(v^*\) such that we have \(c^* \in \textsf{Enc}(pk, v^*)\) and \(c \in \textsf{Enc}(pk, v^*)\), where \(p_s\) is the soundness level of \(\pi _{\textsf{ReRand}}\). Furthermore, since \(\textsf{Verify}\) returns 1, by the property of special decryption \(\textsf{Dec}'\), we have \(c^* \in \textsf{Enc}(pk, v)\) and hence \(v = v^*\). This means that \(c \in \textsf{Enc}(pk, v)\) with probability \(p_s\).

Zero-knowledge: We can construct a simulator \(\textsf{Sim}\), which does not have access to the witness r and which replaces \(\textsf{Prove}\) in the re-written protocol, as follows:

  1. 1.

    \(\textsf{Sim}\) chooses \(r^* \xleftarrow {\$} R\), computes \(c^* \leftarrow \textsf{Enc}(pk, v; r^*)\), and returns \((r^*, c^*)\).

  2. 2.

    \(\textsf{Sim}\) simulates the interactive ZKP \(\pi _{\textsf{ReRand}}\) without knowledge of x.

Due to the ZK property of \(\pi _{\textsf{ReRand}}\), the verifier is not able to distinguish a real execution and a simulated one with probability \(p_z\), where \(p_z\) is the ZK level of \(\pi _{\textsf{ReRand}}\).

4.2 Simulatability Towards Voting Server

Recall that in the basic ballot submission protocol, the only data that \( VS \) obtains from the voter is the voter’s encrypted choice \(c = \textsf{Enc}(pk, v; r)\). Due to the semantic security of the public-key encryption scheme \(\mathcal {E}\), the probability that \( VS \) can derive any information about the voter’s vote v is negligible (if \( VS \) is computationally bounded).

Now, in what follows, we show that the voting server \( VS \) does not learn more information about the voter’s vote in the cast-as-intended protocol than what \( VS \) learns in the basic ballot submission protocol. To this end, we compare the voting server’s view in both protocols and show that all additional interaction between those participants that know/learn the voter’s vote (i.e., voter V herself, her voting device \( VD \), and her audit device \( AD \)) on the one side and the voting server \( VS \) on the other side can be perfectly simulated without any knowledge of the voter’s vote v.

From the voting server’s perspective, the basic ballot submission protocol can be re-written as follows, where \(\hat{V}\) is the unification of the programs of V and \( VD \):

  1. 1.

    \(\hat{V}\) chooses randomness \(r \xleftarrow {\$} R\), computes ciphertext \(c \leftarrow \textsf{Enc}(pk, v; r)\), and sends c to voting server \( VS \).

From the voting server’s perspective, the cast-as-intended protocol (i.e., verifiable ballot submission followed by cast-as-intended verification) can be re-written as follows, where \(\hat{V}_{ext}\) is the unification of the programs of V, \( VD \), and \( AD \):

  1. 1.

    \(\hat{V}_{ext}\) chooses randomness \(r \xleftarrow {\$} R\), computes ciphertext \(c \leftarrow \textsf{Enc}(pk, v; r)\), and sends c to voting server \( VS \).

  2. 2.

    Voting server \( VS \) chooses blinding factor \(x \xleftarrow {\$} R\), computes ciphertext \(c^* \leftarrow \textsf{ReRand}(pk, c; x)\), and sends \((c^*,x)\) to voting device \(\hat{V}_{ext}\).

  3. 3.

    \( VS \) and \(\hat{V}_{ext}\) run interactive ZKP \(\pi _{\textsf{ReRand}}\) with joint input \(pk, c, c^*\) and voting server’s secret input x in order to prove/verify that \(c^*\) is a re-randomization of c.

Due to the re-written presentations of the two protocols, it is easy to see that from the voting server’s perspective, the only task carried out by \(\hat{V}_{ext}\) in the cast-as-intended protocol in addition to \(\hat{V}\)’s tasks in the ballot submission protocol is executing the verification program of the interactive proof \(\pi _{\textsf{ReRand}}\). Observe that the verification program of \(\pi _{\textsf{ReRand}}\) can be executed by any party which knows \((pk, c, c^*)\); in particular no knowledge about the voter’s vote v or randomization elements \(r, r^*\) is required. We can therefore perfectly simulate \(\hat{V}_{ext}\)’s additional program in the cast-as-intended protocol. Using the standard (simulation) argument that the voting server \( VS \) could run the simulation algorithm (in our case: the verification program of \(\pi _{\textsf{ReRand}}\)) itself, we conclude that the voting server \( VS \) does not learn more information about the voter’s vote in the cast-as-intended protocol than what \( VS \) learns in the basic ballot submission protocol.

Remark 1

In the individually verifiable ballot submission protocol described above, the voting server \( VS \) does not learn whether the voter accepted or rejected a protocol run, i.e., whether \(\hat{V}_{ext}\) returned 0 or 1. Depending on the overall voting protocol specification, \( VS \) may however learn the final output of \(\hat{V}_{ext}\), for example, when the voting protocol requires that each voter submits a confirmation code to the voting server after she completed her cast-as-intended verification successfully in order to publicly confirm that V accepts the submitted ballot (see, e.g., [11]).

We note that even if \( VS \) learns the output of \(\hat{V}_{ext}\), ballot privacy towards a possibly corrupted \( VS \) is still guaranteed in our cast-as-intended protocol. In order to prove this claim, we show that the probability of the event that the execution of \(\pi _{\textsf{ReRand}}\) returned 1 but \(v \ne \textsf{Dec}(pk, c^*, r + \tilde{x})\) holds true, where \((c^*, \tilde{x})\) is the output of \( VS \), is negligible. Let us consider the set of runs in which this event holds true. Due to the soundness of \(\pi _{\textsf{ReRand}}\), there exists \(x \in \mathcal {R}\) such that \(c^* = \textsf{ReRand}(pk, c; x) = \textsf{Enc}(pk, v; r+x)\). Now, if \(v \ne \textsf{Dec}'(pk, c^*, r + \tilde{x})\), then there exists \(\tilde{v} \ne v\) such that \(c^* = \textsf{Enc}(pk, \tilde{v}; r+\tilde{x})\) holds true. Due to the correctness of the PKE scheme \(\mathcal {E}\), it follows that \(v = \textsf{Dec}(sk, c^*) = \tilde{v}\), which is a contradiction to \(v \ne \tilde{v}\).

We can therefore conclude that the slightly extended cast-as-intended protocol can be simulated (with overwhelming probability) exactly as in the case above where \( VS \) does not learn the output of \(\hat{V}_{ext}\) when we additionally specify that the simulator returns 1 to \( VS \) if and only if \(\pi _{\textsf{ReRand}}\) returns 1. Note that the simulator does not need to check whether \(v = \textsf{Dec}(pk, c^*, r^*)\) and hence does not need to know v.

5 Full Individual Verifiability

In the previous two sections, we presented the method for cast-as-intended verifiability and analyzed the security properties of this method. Cast-as-intended, which enables the voter to audit his/her ballot and check that it contains the intended choice, does not, however, fully cover the notion of individual verifiability. What is missing is the guarantee that the audited ballot takes part in the tally (sometimes called recorded-as-cast).

In this section, we add the standard mechanism to achieve recorded-as-cast verifiability: a public bulletin board and signed receipts. We also state the higher level security properties such a final system provides. The content of this section can be seen as an example for how our cast-as-intended mechanism can be embedded in a more complete protocol to provide full individual verifiability.

As noted, we introduce an additional participant: the public bulletin board. It is used to collect all the cast ballots, where ballots are published together with unique (possibly anonymised) voter identifiers. We assume that the voters (or auditors) have access to this public bulletin board (during and/or after the ballot cast process) and can check that a given ballot is included there.

We also assume that the voting server has a (private) signing key and that the corresponding (public) verification key is publicly known.

The modifications to the protocol presented in Sect. 3 are straightforward. The changes in the ballot submission protocol are as follows.

  • The encrypted ballot c submitted in Step (BS2) is published by the voting server on the public bulletin board together with a unique voter’s identifier.

  • In step (BS3), the voting server \( VS \) additionally sends to the voting device \( VD \) a signed ballot cast confirmation s, that is a signature on the cast ballot c along with the voter identifier. The signature s is then checked by the voting device \( VD \) and s is given to the voter in Step (BS4).

We also consider the following changes in the ballot audit process:

  • The voting server \( VS \), in Step (BA2), sends additionally to the audit device \( AD \) the ballot cast confirmation s, as in the step above. The audit device checks that s contains a valid signature of the voting server on c and the identifier of the voter (who carries out the ballot audit process).

  • In the final step of the ballot audit process, the voter is given the signed ballot cast confirmation.

Note that the ballot cast confirmation is provided to the voter twice: once by the voting device and then by the audit device. It is expected that these confirmations are exactly the same (which is the case when both devices are honest).

With such receipt, the voter, having executed the ballot audit process, has the following guarantees which directly follow from the results of Sect. 4.

Theorem 2 (informal)

Assume that at least one of the voter devices (the voting device or the audit device) is honest. If the voter successfully carried out the ballot cast process and the ballot audit process, then the voter is in the possession of ballot confirmation which (1) is correctly signed by the voting server, (2) refers to an encrypted ballot that contains the voter’s intended choice (as shown to the voter and confirmed in the ballot audit process) and that is uniquely assigned to this voter.

At the same time, the second device (even if it behaves dishonestly) is not able to produce a convincing evidence for a third party about the voter’s choice.

With this result, given that one of the devices is honest, the voter can check that their ballot, containing their intended choice, is included in the public bulletin board (and if not, given the valid signature, the voter can demonstrate that the voting server misbehaved) and by this also included in the final tally (where the correctness of the tallying process is given due to the universal verifiability). Note that the second part of property (2) of the above theorem protects against clash attacks [23], where different voters audit the same ballot, each believing that the ballot belongs to herself/himself only.

Note that to strengthen this result, the voter can even carry out the ballot audit process using more than one device. With this, even if only one of these devices was honest, it would be enough to guarantee cast-as-intended.

6 Instantiations

Our cast-as-intended protocol can be instantiated with common cryptographic primitives. Our protocol can therefore be used to extend important e-voting protocols for cast-as-intended verification. In this section, we describe the natural instantiation of our method based on the standard ElGamal group; an instantiation for commitment-based e-voting schemes is presented in the full version of this paper.

Let us consider an ElGamal group of order q with a generator g. In this setting, the public key is of the form \(h = g^{sk}\), where \(sk \in Z_q = \{0,\dots ,q-1\}\). Given a plaintext message message \(m \in Z_q\), the encryption of m with randomness r is \(c = (g^r, m\cdot h^{r})\).

Special Decryption: For a ciphertext of the form \(c = (u,w)\) encrypted using randomness r (which means that \(u = g^r\) and \(w = m\cdot h^{r}\)), the randomness r allows one to easily extract the plaintext message by (checking that u is in fact \(g^r\) and) computing \(w \cdot h^{-r}\).

Re-randomisation of a ciphertext \(c = (u,w)\) is of the form \(c' = (u', w')\) where \(u' = u \cdot g^x\) and \(w' = w \cdot h^x\). In order to prove that \(c'\) is a re-randomisation of c, one can use the well-known sigma-protocol for equality of discrete logarithms, that is the proof of knowledge of x such that \(X = \frac{u'}{u} = g^x\) and \(Y = \frac{w'}{w} = h^x\) [6], and transform it into an interactive zero-knowledge protocol using, for instance, the technique from [17, 24] (note that the sigma protocol cannot be used directly, because it is only honest-verifier zero knowledge and is not known to provide the zero-knowledge property in the general case). A detailed instantiation is provided in the full version of this paper.

We note that the computational cost of this method is low and the protocol can, therefore be easily handled even by low-end general purpose devices: There is essentially no extra cost on the voting device (no additional modular exponentiations). On the server (prover) side, the ballot audit process requires 6 modular exponentiations (2 for re-randomisation and 4 for the ZKP). The audit device (verifier) needs 8 modular exponentiations: 6 for the ZKP and 2 for special decryption To put this number in a perspective, it is comparable to the cost of ballot preparation in a typical ElGamal-based voting system which, in the simplest case, requires 3 modular exponentiations. For an implementation using elliptic-curve-based ElGamal group, on an Android phone with a relatively modern CPU (Qualcomm® Snapdragon 865 CPU) the ballot audit process takes only roughly 0.08 s, for a simple ballot which can be encoded as one group element, and it scales linearly with ballot length.