# Making Code Voting Secure Against Insider Threats Using Unconditionally Secure MIX Schemes and Human PSMT Protocols

## Abstract

It is clear to the public that when it comes to privacy, computers and “secure” communication over the Internet cannot fully be trusted. Chaum introduced code voting as a solution for using a possibly infected-by-malware device to cast a vote in an electronic voting application. He trusted the mail system. However, a conspiracy between the mail system and the recipient of the cast ballots breaks privacy. Considering a *t*-bounded passive adversary, we remove the trust in the mail. We propose both single and multi-seat elections, using PSMT protocols (SCN 2012) where with the help of visual aids, humans can carry out mod10 addition correctly with a 99 % degree of accuracy. We introduce an unconditionally secure MIX based on the combinatorics of set systems.

### Keywords

Voting systems Internet voting Information theoretic anonymity Private and secure message transmission Computer system diversity## 1 Introduction

Electronic voting over the Internet enables to cast votes from *any* computer connected to physical Internet accessible location. There is no need to be physically present at a polling station, a disadvantage of booth based electronic voting systems developed by the cryptographic community [8].

Even though secure Internet voting is in its infancy, many countries and organizations are considering adoption or have already done so, such as Switzerland [1] and Estonia [27] where participation increased by 17 % [28]. Similarly, after IACR used the Helios Internet voting system [24], voting increased from 20 % to around 30 %–40 %.

Home computers are vulnerable to security attacks and are easy to hack. So, experts agree that achieving secure Internet voting will be even more difficult than booth-based electronic voting (see e.g., [2, 22]). Modern browsers are vulnerable to attacks - as demonstrated against Helios 2.0 Internet voting in [19]. Already in 2001 Chaum proposed a breakthrough solution called “code voting” [6], where one can use a possibly hacked computer.

In code voting, a voter receives through the *postal mail* a long enough unique code for every candidate. Voters just enter the code corresponding to the candidate of their choice. Chaum’s approach assumes the postal mail to be secure from a reliability and privacy viewpoint. Unfortunately, a collaboration of the postal service with the returning officer^{1} may allow for the anonymity of all votes to be broken by divulging the identity of voters to whom specific voting codes were delivered. Other problems that relate to active attacks against code voting are described in [14].

In Chaum [7] MIX-networks, proposed for anonymity, senders input encrypted messages. The MIX-network outputs each message to all recipients (see Sect. 2.1 for a survey). Their security is conditional. No conditional secure cryptosystem designed so far has withstood cryptanalysis for more than 300 years. Quantum computers will undermine computational voting schemes cryptographers have proposed, in particular these based on ElGamal. This motivates an unconditionally secure voting scheme. Note that for many goals other than voting, unconditionally secure solutions have already been proposed.

The importance of requiring unconditional vote security is further highlighted with the following example:

In 2020 Alice turns 18 and votes using a popular ElGamal based electronic voting scheme. 50 years later, Alice is a candidate for president of the USA. Imagine that in 2070 USA politics is going through a new McCarthy witch hunt. Unfortunately for Alice, ElGamal security has since been broken. The newspapers find that Alice voted for the what is then considered the “

wrong” party!

We propose an *unconditional secure* MIX construction with *t* insiders corrupted by a passive adversary, which cannot cause deviation of protocol execution in any way. Our solution considering an active adversary will be presented in a future full version of this paper.

To deal with foreign governments who might have hacked hardware and software, we employ a *diversity of computing systems*. We consider the *t*-bounded computationally unlimited adversary to be capable of taking control of a total of at most *t* nodes between the vote authority and the voters which includes nodes in the MIX-network, nodes in the communication network or voters computational devices (through malware).

Considering a *t*-bounded adversary we emphasize the following:

**Important Statement 1**

As shown in [20], when the number of corrupted nodes is at most *t*, the minimum number of disjoint paths to allow for private communication between a sender and a receiver is \(t+1\).

**Corollary 1**

Because of the above, voters will have to use a number of computing devices to securely receive (or dually send) their voting codes.

Note that *nowadays, many people in developed countries can have effortless access to more than one device* such as PC’s, laptops, smartphones and tablets. These devices could be owned or from friends and relatives, or available to the public (such as at libraries). These devices can be connected to a communication network in a different manner (Internet or cellular), using different providers and run different operating systems.

The protocols in [4] use humans and avoid relying on a fully trusted computer (see also [18]). We follow a similar approach in the context of Internet voting. We propose unconditionally secure Internet code voting solutions for single seat and multi-seat elections, both user friendly, to guarantee high accuracy.^{2}

Our solution can also be used for other established code voting schemes as it is a way of removing the use of a possibly untrusted mail system and transmitting the voting codes securely, reliably and anonymously to voters.

The text is organized as follows. Background and relevant previous work are presented in Sect. 2. In Sect. 3 a high level description of the protocol is given and we identify the required cryptographic tools. In Sect. 4 we provide a simplified version of the MIX private and anonymous communication protocol. This is used in Sect. 5 in a more efficient manner where we present private and anonymous communication protocols for the transmission of voting codes to voters for single seat and multi seat elections. Section 6 presents the electronic code voting protocol.

## 2 Background and Previous Related Work

### 2.1 Previous Related Work

MIX-networks can be constructed using a shuffle (permutation). One way of achieving this [26, 32] is by using approaches which are based on zero-knowledge arguments [21, 35]. In [15] the use of zero-knowledge was avoided. MIX-networks based on zero-knowledge arguments can be used in electronic voting protocols - as proposed in [23]. Earlier work [31] similarly used shuffles in electronic voting based on zero-knowledge proofs. Other work on MIX-networks includes the work of Abe in [3]. Such constructions are based on computational assumptions which only allow for *conditional security*. The work we present is based on the stronger model of *unconditional security*.

Anonymity in practice is difficult to achieve. One proposed implementation was that of [25] but it was shown to be insecure in [33].

In EVOTE2014, [30] addressed a similar problem to our work. The solution though achieves conditional security and the authors consider the adversary to be present in the MIX network only. This does not take into account the possible presence of malware upon the tablets with which voters will use to cast their votes. Passive malware could possibly identify to an adversary how someone voted, whereas active malware could alter the way someone votes - thus rigging the result of an election.

A voting scheme similar to the one we propose which achieves information theoretic security and requires the voter to carry out modular addition is that presented in [29]. Contrary to the voting scheme proposed in this paper, the work of [29] is *not* an Internet voting scheme as it requires voters to cast their votes at a polling station.

The work of [11] describes an election scheme which requires computational modular exponentiation operations to be carried out by voters. These operations require software or hardware. Furthermore, public key-cryptography is used, meaning that the security properties achieved are computational and not information theoretic - as achieved in our scheme.

### 2.2 Message Transmission Security Properties

We define security properties considering a setting where a single receiver *S* is connected to *m* number of senders (\(r_1,\cdots ,r_m\)) over a possibly corrupt underlying network. For formal definitions, see [17].

**(Perfectly) Correct** - When the receiver accepts a message, it was sent by a sender *S*.

**(Perfectly) Reliable** - When a sender *S* transmits a message, this message will be received by the receiver with probability 1.

**(Perfectly) Private** - Only the designated receiver(s) can read a message transmitted by *S*. i.e., for any coalition of *t* parties, their probability of correctly determining a message is the same whether the coalition is given their transmission view or not.

**(Perfect) Security** - Means perfect correctness, perfect reliability and perfect privacy.

**(Perfectly) Anonymous** - Considering the single receiver wants to receive *m* different messages - one from each *m* number of senders, perfect anonymity is achieved when for any coalition of *t* parties, their probability of correctly determining the sender of *any* message is the same whether the coalition observes the transmission view or not. In the context of Internet voting, perfect anonymity is achieved when the voting protocol used does not facilitate any party in the voting process to correlate any cast vote to a specific voter with greater probability than any other.

### 2.3 Existential Honesty

Some of our ideas use concepts of *existential honesty*, defined in [15] as:

“It is possible to divide the MIX servers into blocks, which guarantee that one block is free of dishonest MIX servers, assuming the number of dishonest MIX servers is bounded by

t.”

To achieve this, [15] defined and used the following^{3}:

**Definition 1**

[10]**.** A set system is a pair \((X,\mathcal{B})\), where \(X \triangleq \{1,\)\( 2, \ldots , m\}\) and \(\mathcal {B}\) is a collection of blocks \(B_i \subset X\) with \(i = 1, 2, \ldots , b\).

**Definition 2**

[15]**.**\((X,\mathcal{B})\) is an (*m*, *b*, *t*)-verifiers set system if \(|X|=m\), \(|B_i| = t+1\) for \(i = 1,2,\ldots ,b\) and for any subset \(F \subset X\) with \(|F| \le t\), there exists a \(B_i \in \mathcal{B}\) such that \(F \cap B_i = \emptyset \).

We *assume that private channels* connect respective MIX servers of corresponding blocks (i.e. MIX server \(MIX_{k,i}\) and \(MIX_{k+1,j}\) are connected with a private channel). We also assume such channels between the receiver and \(MIX_{1,i}\) and similarly, between \(MIX_{b,i}\) and the sender.

### 2.4 Human Perfectly Secure Message Transmission Protocols

Perfectly secure message transmission (PSMT) protocols where the sender or receiver is a human were introduced in [18]. In such protocols it is assumed that the human receiver does *not* have access to a trusted device since these may be faulty and/or infected with malware. Because the receiver is a human, such protocols aim to achieve perfectly secure message transmission (PSMT) in a computationally efficient and computationally simple manner. It is also important that the amount of information and operations the human receiver should process be kept to a minimum.

Addition \({\text {mod}} 10\) was used by humans in these protocols [18] to reconstruct the secret message of the communication protocol from received shares through addition \({\text {mod}} 10\). The idea of using addition \({\text {mod}} 10\) for human computable functions was also used in [4] but within a different security context. By regarding in [18] \(Z_{10}(+)\) as a subgroup of \(S_{10}\) the operation became very reliable for humans to perform. Experiments have shown that given clear, correct and precise instructions, coupled with visual aids, allowed for the correct usage of these protocols by a very high percentage of human participants.

### 2.5 Secure Multiparty Computation in Black-Box Groups

Black box multiparty computation protocols against a passive adversary for non-Abelian group have been presented in [9] and in [13] through the use of a *t*-reliable *n*-coloring admissible planar graph. These papers studied in particular the existence of secure *n*-party protocols to compute the *n*-product function \(f_G(x_1,\)\(\cdots ,\)\(x_n) := x_1 \cdot \ldots \cdot x_n\) where each participant is given the private input \(x_i\) from some non-Abelian group *G* where \(n\ge 2t+1\). It was assumed that the parties are only allowed to perform black-box operations in the finite group *G*, i.e., the group operation \(((x, y) \mapsto x \cdot y)\), the group inversion \((x \mapsto x^{-1})\) and the uniformly random group sampling (\(x \in _R G\)).

## 3 Secure Code Voting with Distributed Security

Assuming the reader is familiar with [6] we present a high level description of the secure code voting protocol we will present in this paper.

### 3.1 High Level Description

We call Code Generation Entity (CGE) the entity which is responsible for creating the codes with which voters will cast their votes. These codes are unique and are sent to the voters so that each of these codes is used only once for the *whole* election. For single seat elections each voter receives as many codes as there are candidates. For multi-seat elections each voter receives a single permutation - which is a permutation of the alphabetical ordering of the candidates. After these codes pass through a MIX network, they will be sent to voters using PSMT. Voters will receive each share using a different device, identify the shares which correspond to the candidate of their choice and reconstruct using human computation this voting code. To cast their vote, voters will send this code back to the CGE via the MIX servers, which perform inverse operations. For each of the received cast codes, the CGE will identify the candidate the code corresponds and will tally up the cast votes for each candidate.

Our protocol does *not* use the mail system for the delivery of voting codes to voters, but instead these are sent by the CGE to voters over a MIX network and using PSMT. Similarly, cast votes will be sent by voters to the CGE over a network as explained in Sect. 6.3.

### 3.2 Required Cryptographic Tools

The process *should not* facilitate the CGE (or any *t* other passive parties) to identify that a specific voter cast a particular vote given that *a number of underlying network nodes may be corrupt*. The use of secret sharing should also allow any protocol to prevent any *t* parties (apart from voters) learning voting codes, otherwise anonymity of votes could be broken.

Human PSMT protocols as presented in [18] are employed. We rely on the feasibility tests performed which confirm that humans can perform these basic operations. We use the secret sharing scheme friendly to humans as presented in [18, Sect. 2.2] which guarantees perfect privacy unconditionally. Except for the voters computing the codes from the shares they receive, all other computations are carried out by computers.

## 4 Transmit and Reply Protocol

In this section we present the first of the required primitives - a perfectly private and perfectly anonymous network communication protocol. For didactic purposes, the simplest form of our proposed protocol will be presented - with more efficient constructions described later.

Suppose that we have a single receiver and *v* senders each of whom needs to receive a secret one time pad so as to send a secret back to the receiver in an interactive anonymous way^{4}.

We assume the passive adversary controls at most *t* MIX servers with each MIX server being involved in one mixing. \(t+1\) blocks of MIX servers will be required - denoted as \(B_1, \ldots , B_{t+1}\), with each block consisting of \(t+1\) MIX servers and we use \(B_k=\{MIX_{k,1},\)\(MIX_{k,2},\)\(\ldots ,\)\(MIX_{k,t+1}\}\) to identify MIX servers of the \(k^{th}\) block and call \(MIX_{k,1}\) “\(B_k\)’s leader”.

### 4.1 Protocol Main Idea

The receiver will share each of the *v* one-time pads into \(t+1\) shares using XOR with each share given to a corresponding MIX server (i.e. one of the \(t+1\) servers) in \(B_1\). The shares of the \(i^{th}\) one-time pad and those of the \(j^{th}\) one-time pad might be transposed and will also be altered. To guarantee shares of the same pad stay together, the transpositions and alterations are chosen by the block leader.

After the last MIX operation, the final block of MIX servers delivers the shares to the senders which reconstruct the received and altered one-time pad sent by the receiver. Each sender will then XOR a secret message with the received altered one-time pad and send the result to the receiver over the MIX network. During this reverse transmission, the inverse alterations will be applied by each block leader.

By XOR’ing the one time pad initially sent out by the receiver, the secret message sent by each sender can be obtained by the receiver.

### 4.2 The MIX Communication Protocol - 1A: Receiver to Sender Transmission

We now present the steps in the MIX communication protocol for the transmission of the one-time pads from the receiver to the set of senders.

**Protocol 1**

*Private and Anonymous Communication Protocol.*

**Step 1.**Let \(\pi ^1_{i}\) be the \(i^{th}\) one-time pad (where \(1\le i\le v\)). The receiver shares each \(\pi ^1_{i}\) into \(t+1\) shares \(\pi ^1_{i,j} \in F_{2^l}\) using XOR (where \(1\le j\le t+1\)) and privately sends \(\pi ^1_{i,j}\) to the corresponding MIX \(MIX_{1,j}\) in block \(B_1\).**Step 2.**The*leader*of \(B_1\) (we call \(MIX_{1,1}\)) informs all others MIX servers in \(B_1\) how they have to permute the*i*-index of all above \(\pi ^1_{i,j}\). This permutation is defined by \(\rho _1\in _R S_v\).**Step 3.**On the*i*indices all MIX servers in \(B_1\) apply the permutation \(\rho _1\). So, \(\pi ^{1}_{i,j}:=\pi ^1_{\rho _1(i),j}\).**Step 4.**The*leader*of \(B_1\) chooses \(t+1\) random bit string modifiers \(\omega ^1_{i,j}\in _R F_{2^l}\) and privately sends \(\omega ^1_{i,j}\) to parties in \(B_1\).**Step 5.**For each (*i*,*j*) the \(t+1\) values \(\pi ^1_{i,j}\) are regarded as shares of \(\pi ^1_{i}\). Similarly, the \(t+1\) values \(\omega ^1_{i,j}\) are regarded as shares of \(\omega ^1_{i}\).The MIX server in \(B_1\) computes \(\pi ^2_{ij}=\omega ^1_{ij} + \pi ^1_{ij}\). \(\pi ^{2}_{i,j}\) are regarded as shares of \(\pi ^{2}\), the \(\rho _1(i)\) permuted and modified one time pad.

**Step 6.**Steps 2–5 are repeated, incrementing by one the indices of \(B_1\) and \(B_2\) until the last block \(B_{b}\) is reached.**Step 7.**Shares held by MIX-servers of block \(B_{t+1}\) are denoted as \(\phi _{i,j}\). \(MIX_{t+1,j}\in B_{t+1}\) then sends \(\phi _{i,j}\) to the \(i^{th}\) sender.

### 4.3 The MIX Communication Protocol - 1B: Sender to Receiver Transmission

Upon the end of the first phase, each sender reconstructs their respective altered one-time pad using XOR over all received shares.

Using XOR, senders encrypt their secret and send this to the *leader* of block \(B_{t+1}\). These are sent back to the receiver in much the same way as transmitted from receiver to sender. This time though data are sent between *leaders* of MIX blocks, with the inverse permutations \(\rho _{b}^{-1}\) and XOR invalidation of modifiers using \(-\omega _{i}^k\) being applied.

The data sent back to the receiver correspond to encrypted messages transmitted by senders. By applying XOR using the respective one-time pad, the secret message transmitted by senders can be obtained.

### 4.4 Security Proof

In this section we present the security proof for Protocol 1.

**Theorem 1**

Protocol 1 is a reliable, private and anonymous message transmission protocol.

*Proof*

The protocol achieves perfect reliability due to the passive nature of the adversary. Perfect privacy is achieved as each one-time pad or encrypted message is “shared” over \(t+1\) shares. As each MIX server is used only once and as the adversary can control at most *t* MIX servers, secrecy of these transmitted data is retained.

We now prove the perfect anonymity of the protocol - for simplicity of the proof we assume that there are only two messages (two one time pads). As \(t+1\) blocks of MIX servers are used and each MIX server is used only once, there exists a block \(B_i\) - \(1 \le i \le b\), free from adversary controlled MIX servers. Because of this, the adversary is unable to learn the modifiers and permutation which are added and implemented respectively to the shares of the messages.

Assuming the adversary is present in \(B_{i+1}\) and absent from \(B_{i}\), the view of the adversary of a share for both messages can be one of the following two possibilities: \((\omega _1^i+\pi ^{i-1}_1, \omega _2^i+\pi ^{i-1}_2), (\omega _2^i+\pi ^{i-1}_2, \omega _1^i+\pi ^{i-1}_1)\)

Obviously, the adversary cannot distinguish between the first and the second possibility as the modifiers and permutation used in block \(B_i\) are random and unknown to the adversary. Indeed, there exists an (\(\omega _1',\omega _2'\)) such that (\(\omega _2^i+\pi ^{i-1}_2,\omega _1^i+\pi ^{i-1}_1\))=(\(\omega _1'+\pi ^{i-1}_1,\omega _2'+\pi ^{i-1}_2\)). So, the adversary cannot distinguish whether the messages have been interchanged or not.

Without loss of generality, the proof can be extended to any number *v* of messages. \(\square \)

## 5 Reducing the Number of MIX Servers

In this section we improve on the “Transmit and Reply Protocol” presented in Sect. 4 presenting a solution for the single seat election case where an Abelian group is used.

Our solution uses Chaum’s code voting and considers a single receiver (e.g., CGE) and *v* human voters who each need to receive voting codes (one code per candidate) in a non-interactive anonymous way. We consider the CGE as the receiver and the human voters as the senders of the communication because at the end of the combined protocol, the human voters will send back to the CGE the voting code which corresponds to the candidate of their choice. We regard codes intended for the same receiver as a long string and the MIX servers MIX the strings (i.e. those intended for different receivers).

A more efficient network of MIX servers is used as our solution is not confined to using each MIX server only once, thus the total number of MIX operations done is *b*. We denote the set of MIX servers by *X* and assume we have an \((X,\mathcal{B})\) set system, which is an (*m*, *b*, *t*)-verifiers set system set system as defined in [15]. We let \(B_k=\{MIX_{k,1},\)\(MIX_{k,2},\ldots ,\)\(MIX_{k,t+1}\}\) and call \(MIX_{k,1}\) “\(B_k\)’s leader”.

The main idea of the protocol is very similar to the communication protocol of the previous section. This time, the receiver (e.g., CGE) will share each of the *v* messages to transmit using an appropriate secret sharing scheme (and not using XOR). In a similar fashion, messages are permuted and altered as they are transmitted within the MIX network. After the last MIX operation, the final block of MIX servers delivers the shares of messages to the senders, with each sender reconstructing the secrets (voting codes) sent by the receiver. We will assume the transmission of the shares of these secrets uses the human friendly method presented in [18]. Similarly, since a code is only used once, it can be modified using addition over a finite Abelian group. To be compatible with [18] one such example is addition \({\text {mod}}10\) over the group used. Senders will then transmit back to the receiver the voting code corresponding to their choice.

### 5.1 Virtual Directed Acyclic Graphs

When an Abelian group is used and when blocks of the (*m*, *b*, *t*)-verifiers set system can share common MIX servers between them, we define the construction of a *virtual* vertex-labeled Directed Acyclic Graph (DAG). The set of vertices of the DAG is composed of parties participating in the protocol (which is similar to Protocol 3), with the source of the graph being the receiver of the protocol and the sink being a sender.

*amongst different levels*in the DAG. We define levels of the DAG as the receiver, a sender and the different blocks of MIX servers used. Considering block \(B_i\) as a tuple (ordered set), when \(B_i\) is a block where \(|B_i|=l\) and \(b\in B_i\), at

*location*

*k*in this tuple, we say that

*b*is at position

*k*. With the above definition, directed edges of the DAG will occur (i) from the receiver to all \(b_j\) in \(B_1\) (\(1\le j\le l\)), (ii) from each \(b_j\) in block \(B_b\) to the sender, (iii) moreover, we have edges between nodes in \(B_i\) and nodes in \(B_{i+1}\). The following is required:

- 1.
If a unique color was to be assigned to each party of the protocol, based on the results of [16], the sender and receiver can privately communicate, if when choosing any

*t*colors and removing the vertices of the DAG with those*t*colors the sender and receiver remain connected - meaning that there still exists a directed path from the sender to the receiver on the reduced DAG. - 2.
We require that if at level

*k*the parties in \(B_{k}\) receive shares of \(\pi _i^k\), the parties in \(B_{k+1}\) (i.e., at level \(k+1\)) receive shares of \(\pi _i^{k+1}\)=\(\omega ^k_i + \pi _{\rho (i)}^k\).

Two methods can be used to achieve the above requirements. One uses re-sharing - such as the redistribution scheme described in [12]. The other uses a large set of MIX servers *X* to guarantee the following property.

**Definition 3**

We say that set *X* of MIX servers is under *t-confinement* if all members of set *T* where \(|T| = t\) appear in at most *t* positions over all blocks of MIX servers used and this for all \(T \subseteq X\) where \(|T| = t\).

It is easy to see that the above satisfies the DAG requirements.

### 5.2 The MIX Protocol

In the case of Internet voting this is used as a pre-voting protocol for the transmission of voting codes to voters and it is used to achieve anonymity of voting codes. We assume *S* to be a finite Abelian group and denote with *v* the number of senders, and thus the number of messages (sets of voting codes) that need to be transmitted. In the following, we only describe the required difference when compared to Protocol 1.

**Protocol 2**

*Private and Anonymous Random Communication Protocol.*

**Step 1.**Let \(s_i\) be the \(i^{th}\) message (where \(1\le i\le v\)). The sender shares each \(s_i\) by choosing*l*shares \(\pi ^1_{i,j}\in _R S\) (using an appropriate secret sharing scheme over an Abelian group where \(1\le j\le l\)) and privately sends \(\pi ^1_{i,j}\) to the corresponding party \(B_{1,j}\) in \(B_1\).- –
As an (

*m*,*b*,*t*)-verifiers set system is used, \(l=t+1\) denotes the number of shares.

- –
**Step 2.**Same as in Protocol 1.**Step 3.**Same as in Protocol 1.**Step 4.**The*leader*of \(B_1\) chooses modifiers \(\omega ^1_{i,j}\in _R S\) and privately sends \(\omega ^1_{i,j}\) to parties in \(B_1\).**Step 5.**Similar as in Protocol 1. Only:The MIX servers in \(B_1\) compute shares of \(\pi ^2_{i}=\omega ^1_{i} + \pi ^1_{i}\), i.e. party \(P_{j}\in B_{i}\) adds the modifiers it receives from the leader of \(B_{i}\) to the share(s) it holds. The shares of the \(\pi ^2_{i}\) are denoted as \(\pi ^{2}_{i,j}\).

**Step 6.**If the concept of*t*-confinement is not used, re-sharing of shares \(\pi ^{2}_{i,j}\) is carried by out by parties in \(B_1\) using the redistribution scheme described in [12]. That means that each party in \(B_2\) receives \(l = t + 1\) values, which they then compress.**Step 7.**Steps 2–5 are repeated incrementing by one the indices of \(B_1\) and \(B_2\) until the last block \(B_{b}\) is reached. For all iterations - except when the last block \(B_{b}\) is reached, Step 6 is also repeated (except if*t*-confinement is used).**Step 8.**If*t*-confinement is not used, shares held by the MIX-servers of block \(B_{b}\) are re-shared.**Step 9.**Shares held by MIX-servers of block \(B_{b}\) are denoted as \(\phi _{i,j}\). \(MIX_{b,j}\in B_b\) then sends \(\phi _{i,j}\) to the \(i^{th}\) voter using [18].

It should be noted, that as in [18], MIX servers will send shares to voters using network disjoint paths, as the communication network cannot be trusted with the adversary capable of listening to at most *t* of these paths. The way voters cast their vote will be described in Sect. 6.

### 5.3 Security Proof

**Corollary 2**

Protocol 2 is a reliable, private and anonymous message transmission protocol.

*Proof*

Formally, we have:

**Perfect Reliability** - This is the same as in Theorem 1.

**Perfect Privacy** - The protocol achieves perfect privacy as each message is “shared” over \(l=t+1\) shares. In the case of *t*-confinement, the view of the adversary will consist of at most *t* shares. This number is one less that the number required to reconstruct a secret and thus perfect privacy is achieved. In the case of re-sharing, the re-sharing guarantees that shares at level *i* are independent of those at level \(i+1\) (note that the adversarial parties are passive). The rest follows from [16] and through the use of re-sharing or *t*-confinement. When using re-sharing we ensure that there is no cut of *t* vertices (colors) that can disconnect the sender and the receiver. This is because the resharing of shares makes certain that the parties in block \(b_i\) receive shares from \(t+1\) parties in block \(b_{i-1}\). So, any adversarial *t* parties in block \(b_{i-1}\) will not allow to cut the graph. It is easy to see that the condition of [16] (i.e. no *t* parties are able to cut a graph) is satisfied when using *t*-confinement thus allowing for secure solutions.

**Perfect Anonymity** - This is very similar to the anonymity proof of Theorem 1. The only difference is that now where a lower number of MIX servers are used, due to Property 3 from the definition of verifier set systems, there exists a block \(b_i\) - \(1 \le i \le b\), free from adversary controlled MIX servers. Because of this, the adversary is unable to learn the modifiers and permutation which are added and implemented respectively to the shares of the messages. \(\square \)

### 5.4 Use of non-Abelian Group - Multi-seat Election Case

When a non-Abelian group is used, the protocol is similar to that presented in Sect. 5.2. Due to the non-Abelian nature of the group, alternative additional techniques will have to be employed to manage the fact that dealing with shares cannot be done locally (due to the multiplication) thus this needs to be shared and securely computed among many parties using techniques presented in [13].

Suppose we have an election in which we have *s* seats in which every voter can vote for up to *s* of the *c* candidates - where \(s\le c\). To enable *blinding* of the code, we give to each voter a secret permutation \(\pi \in S_c\), where \(S_c\) is the symmetric group. For each favourite candidate *i* the voter wants to vote for, \(\pi (i)\) is transmitted to the returning officer.

Note that \(\pi \) is *not* necessarily unique to the election, as opposed to Chaum’s code voting. The protocol is organized to avoid that this creates a problem. In the case of Internet voting, the following protocol is used as a pre-voting protocol, for the transmission of *v* number of voting “codes” (i.e. permutations) to *v* number of voters and it is used to achieve anonymity of voting codes. We assume \(S=S_c\) to be a finite non-Abelian group.

It should be noted that the protocol to be presented is only useful for the private and anonymous transmission of permutations with which receivers can cast their vote.

**Protocol 3**

**Step 1.**Same as in Protocol 2 only now a non-Abelian group is used and permutations are transmitted.**Step 2.**The*leader*of \(B_2\) chooses modifiers \(\omega ^2_{i,j}\in _R S_c^l\) and privately sends \(\omega ^2_{i,j}\) to parties in \(B_2\) such that the*l*values \(\omega ^2_{i,j}\) are regarded as shares of \(\omega ^2_{i}\).^{5}**Step 3.**For each (*i*,*j*) the*l*values \(\pi ^1_{i,j}\) are regarded as shares of \(\pi ^1_{i}\). The MIX servers in \(X'_{1,2} \subseteq X\) where \(|X'_{1,2}| \ge 2t+1\) and \(B_1 \cup B_2 \subseteq X'_{1,2}\) compute shares of \(\pi ^{2}_{i}=\omega ^2_{i}\circ \pi ^1_{i}\) using a black box non-Abelian multiparty computation protocol^{6}(see Sect. 2.5). This is done so that \(\omega ^2_{i}\) blinds \(\pi ^1_{i}\). The shares of the product are denoted as \(\pi ^{2}_{i,j}\) and are obtained by the parties^{7}in \(B_2\).**Step 4.**The*leader*of \(B_2\) informs all other MIX servers in \(B_2\) how they have to permute the*i*-index of all shares they hold from the above operations. This permutation is defined by \(\rho _2\in _R S_v\). On the*i*indices the MIX servers in \(B_2\) apply the permutation \(\rho _2\). So, \(\pi ^{2}_{i,j}:=\pi ^2_{\rho _2(i),j}\).**Step 5.**The above three steps are repeated by incrementing by one the indices of \(B_1\) and \(B_2\) (thus \(B_k \ne B_{k+1}\)). After parties in \(B_k\) permute the*i*indices of \(\pi ^{k}_{i,j}\) using \(\rho _k\) - where \(2 \le k \le b-1\), the*leader*of \(B_{k+1}\) chooses modifiers \(\omega ^3_{i,j}\in _R S_c^l\) which are given to parties in \(B_k\), the black box non-Abelian multiparty computation sub-protocol is executed by parties in \(X'_{k,k+1} \subseteq X\) where \(B_k \cup B_{k+1} \subseteq X'_{k,k+1}\)\(|X'_{k,k+1}| \ge 2t+1\) and the process continues till the final block of servers \(B_b\) is reached.**Step 6.**After parties in \(B_b\) permute the*i*indices of \(\pi ^{b}_{i,j}\) using \(\rho _b\), the*leader*of \(B_1\) chooses modifiers \(\omega ^1_{i,j}\in _R S_c^l\) which are given to parties in \(B_1\), the black box non-Abelian multiparty computation sub-protocol is executed between parties in block \(B_b\) and \(B_1\) and the output of which is held by parties in \(B_1\). \(MIX_{1,j}\in B_1\) sends the output it holds to the \(i^{th}\) voter using [18].

It should be noted, that as in [18], MIX servers will send shares to voters using network disjoint paths, as the communication network cannot be trusted with the adversary capable of listening to at most *t* of these paths. The way voters will use what they receive to cast their vote will be described in Sect. 6.

**Theorem 2**

Provided Protocol 3 together with the appropriate black box non-Abelian multiparty computation sub-protocol is used, then Protocol 3 is a reliable, private and anonymous random transmission protocol.

The proof of the above theorem is similar to the proof of Theorem 1, but relying on either [9, 13].

## 6 Electronic Code Voting Protocol

We now outline how components of previous sections are combined.

### 6.1 Preparation, Mixing and Transmission of Voting Codes

As described in Sect. 3.1 the CGE is responsible for creating the codes with which voters will cast their votes. We first explain this for the single-seat election.

Considering an election has *c* number of candidates and that there are *v* number of voters, the CGE will create *v* random *initial* codes for each of the *c* candidates. In total, \(c \times v\) unique number of codes will be generated. The CGE will then group these codes to form *v* number of \(c-tuples\), with each tuple containing a single code for each of the *c* candidates.

Each of these codes will then be transmitted as one-time pads to the voters in the same way as described by Protocol 2. It should be noted that Protocol 2 describes the transmission of only *v* codes as opposed to \(c \times v\) required by the voting protocol. To transmit all the voting codes, *c* executions of Protocol 2 will be executed at the same time. These executions should *not be independent between them but instead should use the same permutations* (\(\rho \in _R S_{v}\) in Step 2) and modifiers (\(\omega _{i,j}\) in Step 4) used throughout all executions of the protocol, i.e. the same modifier is used for all codes the same voters will receive and they remain bundled together (i.e. by reusing \(\rho \)). These *c* executions can be carried out either in parallel or sequentially, as long as each voter receives *c* voting codes.

In the case of multi-seat elections, each voter will receive a single permutation over \(S_c\) - which is a permutation of the alphabetical ordering of the candidates. Moreover, Protocol 3 will be used.

### 6.2 Receiving and Reconstructing Voting Codes

We first explain the single-seat case. Each voter will receive \(l=t+1\) shares for each voting code, receiving each one using a *different* computational device. It should be noted that the \(i^{th}\) share of each of the *c* voting codes will be received upon the *same* computational device.

A voter can then identify the code for their chosen candidate. Once all pieces of each code are received, the code corresponding to their choice can be reconstructed in a similar manner as described in Sect. 2.4.

In the multi-seat election, instead of receiving a *c*-tuple, a single permutation is received - which is a permutation of the alphabetical ordering of the candidates. Similar to the single seat case, \(t+1\) shares of this permutation will be received by the voter who will reconstruct the permutation as described in [18, Sects. 4.2 and 4.3]. This will allow the voter to identify the candidates of their choice. Supposing the voter wants to vote for candidate *c* and candidate \(c'\), the reconstruction of the permutation will help the voter identify \(\pi (c)\) and \(\pi (c')\) which correspond to the candidates of their choice. To cast their vote, voters will have to send back to the CGE these \(\pi (c)\) and \(\pi (c')\) values.

### 6.3 Transmission, Mixing and Counting of Cast Votes

We first explain for the single-seat case. A voter identifies the code corresponding to their chosen candidate and sends this code back to the CGE by transmitting this code *to the leader* of the last block of MIX.

To transmit voter codes in the reverse direction (towards the CGE), *the leaders* of each block of MIX servers will have to carry out the reserve operations on the codes. Thus the inverse permutations (\(\rho _{b}^{-1}\)) and modifiers (\(-\omega _{i}^k\)) are used. Once a code arrives to the CGE, it will identify the candidate it corresponds to and the vote will be counted.

The multi-seat case is similar. Voter identify the \(\pi (c)\) corresponding to one of their chosen candidates and send this \(\pi (c)\) to the leader of the last block of MIX servers. Similar to the single-seat case, the reverse operations on the codes will be carried out. Once a voter’s \(\pi (c)\) arrives to the CGE, the CGE will apply \(\pi ^{-1}\) and identify the candidate the voting corresponds to and the vote will be counted.

## Footnotes

- 1.
A returning officer oversees elections in one or more constituencies [34].

- 2.
- 3.
See also [18, Sect. 2.3] for an extensive description of set systems and how these relate to covering designs.

- 4.
The dual problem is that instead of having

*v*senders, we have*v*receivers and one sender. Obviously a solution for the first provides a similar solution for the second. - 5.
As shown in [13], to securely compute \(\pi \) and \(\omega \) where \(\pi \) is chosen by one party and \(\omega \) by another, we need \(2t+1\) parties with

*t*curious parties. To mimic as closely as possible the working of [13], the leader of \(B_2\) chooses \(\omega ^2_{i,j}\) and*not*the leader of \(B_1\). - 6.
Note that the MIX servers in \(B_1 \cup B_2\) can also be a in \(X'_{1,2}\) where \(|X'_{1,2}| \ge 2t+1\). Additionally, the efficiency of black box non-Abelian multiparty computation protocols is better when \(|X'_{1,2}| >> 2t+1\).

- 7.
Note that [13] allows to organize the computation such that the output, i.e. shares of \(\pi ^{2}_{i}\), are received by parties in \(B_2\).

## Notes

### Acknowledgments

The authors would like to thank the anonymous referees for their valuable comments on improving the presentation and clarity of this paper. We thank Rebecca Wright for having co-invented the concept of having anonymous communication allowing a receiver to reply anonymously to the sender. The authors would also like to thank Juan Garay and Amos Beimel for expressing their interests in PSMT in which one cannot trust the equipment used by the receiver.

### References

- 1.E-voting. https://www.ch.ch/en/online-voting/
- 2.Four Grand Challenges in Trustworthy Computing. In: CRA Conference on Grand Research Challenges in Information Security and Assurance, Warrenton, Virginia, 16–19 November 2003Google Scholar
- 3.Abe, M.: Universally verifiable mix-net with verification work independent of the number of mix-servers. In: Nyberg, K. (ed.) EUROCRYPT 1998. LNCS, vol. 1403, pp. 437–447. Springer, Heidelberg (1998) CrossRefGoogle Scholar
- 4.Blocki, J., Blum, M., Datta, A.: Human computable passwords. CoRR (2014)Google Scholar
- 5.Buchmann, J., Demirel, D., van de Graaf, J.: Towards a publicly-verifiable mix-net providing everlasting privacy. In: Sadeghi, A.-R. (ed.) FC 2013. LNCS, vol. 7859, pp. 197–204. Springer, Heidelberg (2013) CrossRefGoogle Scholar
- 6.Chaum, D.: SureVote: technical overview. In: Proceedings of the Workshop on Trustworthy Elections, Tomales Bay, CA, USA, 26–29 August 2001Google Scholar
- 7.Chaum, D.: Untraceable electronic mail, return addresses, and digital pseudonyms. Commun. ACM
**24**(2), 84–88 (1981)CrossRefGoogle Scholar - 8.Chaum, D., Essex, A., Carback, R., Clark, J., Popoveniuc, S., Sherman, A.T., Vora, P.L.: Scantegrity: end-to-end voter-verifiable optical-scan voting. IEEE Secur. Priv.
**6**(3), 40–46 (2008)CrossRefGoogle Scholar - 9.Cohen, G., Damgård, I.B., Ishai, Y., Kölker, J., Miltersen, P.B., Raz, R., Rothblum, R.D.: Efficient multiparty protocols via log-depth threshold formulae. In: Canetti, R., Garay, J.A. (eds.) CRYPTO 2013, Part II. LNCS, vol. 8043, pp. 185–202. Springer, Heidelberg (2013) CrossRefGoogle Scholar
- 10.Colbourn, C.J., Dinitz, J.H.: Handbook of Combinatorial Designs. Discrete Mathematics and Its Applications, 2nd edn. Chapman & Hall/CRC, Boca Raton (2006) CrossRefGoogle Scholar
- 11.Cramer, R., Franklin, M.K., Schoenmakers, B., Yung, M.: Multi-authority secret-ballot elections with linear work. In: Maurer, U.M. (ed.) EUROCRYPT 1996. LNCS, vol. 1070, pp. 72–83. Springer, Heidelberg (1996) CrossRefGoogle Scholar
- 12.Desmedt, Y., Jajodia, S.: Redistributing secret shares to new access structures and its applications. Technical Report ISSE-TR-97-01, George Mason UniversityGoogle Scholar
- 13.Desmedt, Y., Pieprzyk, J., Steinfeld, R., Sun, X., Tartary, C., Wang, H., Yao, A.C.-C.: Graph coloring applied to secure computation in non-abelian groups. J. Cryptol.
**25**(4), 557–600 (2012)MathSciNetCrossRefGoogle Scholar - 14.Desmedta, Y., Erotokritou, S.: Making Code Voting Secure against Insider Threats using Unconditionally Secure MIX Schemes and Human PSMT Protocols. https://www.cyi.ac.cy/images/ResearchProjects/SteliosE/voteID2015Final Short.pdf
- 15.Desmedt, Y.G., Kurosawa, K.: How to break a practical MIX and design a new one. In: Preneel, B. (ed.) EUROCRYPT 2000. LNCS, vol. 1807, pp. 557–572. Springer, Heidelberg (2000) CrossRefGoogle Scholar
- 16.Desmedt, Y.G., Wang, Y., Burmester, M.: A complete characterization of tolerable adversary structures for secure point-to-point transmissions without feedback. In: Deng, X., Du, D.-Z. (eds.) ISAAC 2005. LNCS, vol. 3827, pp. 277–287. Springer, Heidelberg (2005) CrossRefGoogle Scholar
- 17.Dolev, D., Dwork, C., Waarts, O., Yung, M.: Perfectly secure message transmission. J. ACM
**40**(1), 17–47 (1993)MathSciNetCrossRefMATHGoogle Scholar - 18.Erotokritou, S., Desmedt, Y.: Human perfectly secure message transmission protocols and their applications. In: Visconti, I., De Prisco, R. (eds.) SCN 2012. LNCS, vol. 7485, pp. 540–558. Springer, Heidelberg (2012) CrossRefGoogle Scholar
- 19.Estehghari, S., Desmedt, Y.: Exploiting the client vulnerabilities in internet e-voting systems: Hacking Helios 2.0 as an example. In: EVT/WOTE 2010 (2010)Google Scholar
- 20.Franklin, M.K., Yung, M.: Secure hypergraphs: privacy from partial broadcast. SIAM J. Discrete Math.
**18**(3), 437–450 (2004)MathSciNetCrossRefGoogle Scholar - 21.Furukawa, J.: Efficient and verifiable shuffling and shuffle-decryption. IEICE Trans.
**88–A**(1), 172–188 (2005)CrossRefGoogle Scholar - 22.Gerck, E., Neff, C.A., Rivest, R.L., Rubin, A.D., Yung, M.: The business of electronic voting. In: Syverson, P.F. (ed.) FC 2001. LNCS, vol. 2339, p. 234. Springer, Heidelberg (2002) CrossRefGoogle Scholar
- 23.Groth, J., Ishai, Y.: Sub-linear zero-knowledge argument for correctness of a shuffle. In: Smart, N.P. (ed.) EUROCRYPT 2008. LNCS, vol. 4965, pp. 379–396. Springer, Heidelberg (2008) CrossRefGoogle Scholar
- 24.Helios. Helios Voting. http://heliosvoting.org/
- 25.Katti, S., Cohen, J., Katabi, D.: Information slicing: anonymity using unreliable overlays. In: Proceedings of the 4th USENIX Symposium on NSDI, Cambridge, Massachusetts, U.S.A., 11–13 April 2007, pp. 43–56 (2007)Google Scholar
- 26.Khazaei, S., Moran, T., Wikström, D.: A mix-net from any CCA2 secure cryptosystem. In: Wang, X., Sako, K. (eds.) ASIACRYPT 2012. LNCS, vol. 7658, pp. 607–625. Springer, Heidelberg (2012) CrossRefGoogle Scholar
- 27.Maaten, E.: Towards remote e-voting: Estonian case. In: Electronic Voting in Europe - Technology, Law, Politics and Society, 7th-9th July 2004. LNI, vol. 47, pp. 83–100. GI, Bregenz (2004)Google Scholar
- 28.Malkopoulou, A.: Lost voters: participation in eu elections and the case for compulsory voting. CEPS Working Document No. 317, 24 July 2009Google Scholar
- 29.Moran, T., Naor, M.: Split-ballot voting: everlasting privacy with distributed trust. ACM Trans. Inf. Syst. Secur.
**13**(2), 16:1–16:43 (2010)CrossRefGoogle Scholar - 30.Rabin, M.O., Rivest, R.L.: Efficient end to end verifiable electronic voting employing split value representations. In: EVOTE 2014, Bregenz, Austria (to appear)Google Scholar
- 31.Sako, K., Kilian, J.: Secure voting using partially compatible homomorphisms. In: Desmedt, Y.G. (ed.) CRYPTO 1994. LNCS, vol. 839, pp. 411–424. Springer, Heidelberg (1994) Google Scholar
- 32.Sampigethaya, K., Poovendran, R.: A survey on mix networks and their secure applications. Proc. IEEE
**94**, 2142–2181 (2006)CrossRefGoogle Scholar - 33.Tran, A., Hopper, N., Kim, Y.: Hashing it out in public: common failure modes of DHT-based anonymity schemes. In: Proceedings of WPES 2009, Chicago, Illinois, USA, 9 November, pp. 71–80 (2009)Google Scholar
- 34.Wikipedia. Returning officer. http://en.wikipedia.org/wiki/Returning_officer
- 35.Wikström, D.: The security of a mix-center based on a semantically secure cryptosystem. In: Menezes, A., Sarkar, P. (eds.) INDOCRYPT 2002. LNCS, vol. 2551, pp. 368–381. Springer, Heidelberg (2002) CrossRefGoogle Scholar