Toward Round-Efficient Verifiable Re-Encryption Mix-Net

Re-encryption mix-nets (RMNs) provide an efficient cryptographic anonymous channel for useful applications such as e-voting and web browsing. Many studies have been devoted to achieving practically efficient RMN protocols, but less attention has been paid to dealing with their round efficiency than to computation and communication measures. However, in many interactive cryptographic protocols, network latency governs the overall execution time. Because e-voting systems are particularly interaction intensive, the design of a round-efficient RMN protocol is of particular interest. We propose a constant-round RMN protocol in a three-party model that consists of senders, mix servers and some number of receivers. Here, the main role of the receivers is to jointly decrypt a list of ciphertexts obtained from the mixing stage. Such an explicit three-party model is most suitable for e-voting applications. We define an ideal three-party RMN in the universally composable (UC) framework. We then present a constant-round RMN protocol based on the standard assumptions and prove that it UC-realizes the ideal three-party RMN with respect to a static adversary that can corrupt a minority of mix servers, disallowing receivers who collude with other players. We implmented and evaluatd our RMN protocol over a various range in the number of senders and mix servers. Our evalulation shows that our protocol runs up to $2.5\times $ faster than Universal RMN protocol. Besides, we provide a detailed theoretical analysis of our protocol in terms of computation, transmission, and round efficiency.


I. INTRODUCTION
Mix networks (for short, mix-nets) are a cryptographic tool for establishing private communication channels in a wide range of applications, for example, secure e-voting systems [1], anonymous e-mail [2], and location privacy in mobile networks [3]. The mix-net of Chaum [4] is run among a set of senders and a set of mix servers, and it works as follows: each sender provides its input to the mix servers, which then privately shuffle all inputs and ultimately publish them in random order.
There are roughly two basic flavors of mix-nets. The first class is known as a re-encryption mix-net (RMN). In this type The associate editor coordinating the review of this manuscript and approving it for publication was Alba Amato . of mix-net, both inputs and outputs are ciphertexts under the public key of some semantically secure cryptosystem with the homomorphic property that allows re-encryption without knowing the corresponding private key (e.g., El Gamal [5] and Paillier [6]). Each mix server re-encrypts the inputs and then permutes them. Because the output is still in the ciphertext, other authorities that had generated a public and private key pair need to decrypt it to produce the set of original messages. The mix servers can take over this role in some cases.
The second class is known as decryption mix-nets (DMNs), which were originally designed by Chaum [4]. The inputs to the mix-net are ciphertexts produced through interactive encryption under the public keys of individual servers. When processing inputs, each mix server decrypts the VOLUME 10, 2022 This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/ layer corresponding to its own public key in each ciphertext and then permutes the resulting ciphertexts. Thus, the final output is produced in cleartext.
Of the two types of mix-nets, our main interest is the RMN because of the weaknesses of the DMN, including the requirements of multiple encryptions by the sender and a predefined order of decryption. In particular, we primarily pay attention to the round efficiency of RMN protocols. Round efficiency is of great importance because network latency usually has an effect several magnitudes greater than that of local computation costs. The round complexity usually dictates the time cost of a cryptographic protocol, and much research effort has been devoted to finding roundoptimal protocols (e.g., see [7], [8], [9] in the MPC area). Nevertheless, little attention has been paid to handling the round efficiency problem in the RMN field. Thus, we focus on the following simple question (Q1).
Is it possible to construct a constant-round RMN protocol? (Q1)

A. PREVIOUS WORK ON THIS QUESTION
In the research on RMNs, just a couple of papers have suggested methods of improving round efficiency in different stages of the RMN. The universal RMN protocol by Golle et al. [10] removes the joint decryption stage from the classical RMN by sending a pair of two El Gamal ciphertexts, where one contains a message and the other contains the public key of the receiver. Relying on Abe's observation that an RMN does not require sequential ordered mixing [11], Golle and Juels [12] proposed a method to perform mixing in parallel, which is called the parallel mix-net.
While these efficiency techniques clearly contribute to reducing network latency in mix-nets, their round efficiency still depends on the number of mix servers. For example, the universal RMN aims to reduce network latency during the group decryption stage. Thus, the round complexity of the universal RMN is linear in the number of mix servers n m (i.e., O(n m )). Moreover, the strong point of the universal RMN can be a weakness in certain circumstances (e.g., when there are multiple receivers); since the mix server outputs a list of only message-containing entries, the receiver needs to exhaustively search every output list received for possible messages encrypted under its public key. The parallel mix-net is somewhat complex. Indeed, the parallel mix-net requires n m rounds for mixing (see Figure 3 in [12]), where the parameterñ m is the number of corrupt mix servers. Clearly, n m < n m , but additionally, the round complexity depends on the threat model, which determines the thresholdñ m . Consequently, prevailing cases such as an honest majority (i.e.,ñ m < n m 2 ) still have O(n m ) round complexity, while in some extreme cases (e.g.,ñ m = n m − 1), almost constant rounds can be achieved. Of course, their benefits in terms of latency are very clear.

B. PROBLEM STATEMENT
We refer to the problem of designing an RMN protocol with constant rounds across mix servers as the problem of finding a round-efficient RMN. More formally, a round-efficient RMN protocol takes as input a list of ciphertexts and outputs a list of plaintexts while hiding the correspondence between the inputs and outputs within a constant number of rounds. Ensuring efficiency in rounds during the mixing stage makes the problem a nontrivial one.
We want to solve the problem in a model that consists of n s senders that each have a plaintext, n m mix servers, and n r receivers. As usual, a mix server takes as input a list of ciphertexts from senders or another mix server, re-encrypts these ciphertexts, and outputs a new list of ciphertexts in a permuted order. Then, a quorum of receivers that share the private key decrypts the final list and outputs a set of plaintexts. In this work, we explicitly separate receivers from mix servers. This explicit three-party structure for the RMN is widely accepted in applications such as e-voting systems, where the tallying authorities can be viewed as the receivers (e.g., [13]).

C. OUR CONTRIBUTIONS AND KEY IDEAS
Inspired by these challenges, the primary contribution of this paper is a round-efficient RMN protocol in the threeparty model. We simply call it a three-party RMN (3RMN) protocol. Specifically, the contributions of this work are summarized below.
• We give the formal 3RMN protocol definition and the notion of security in the 3RMN and instantiate it by making use of several cryptographic tools (more precisely, they should be universally composable). In particular, we show that our 3RMN protocol requires only O (1) round complexity in the number of mix servers.
• To prove the practical effectiveness of our approach, we implement our RMN protocol. Our experimental results show that our protocol runs upto 2.5× faster than our competitor [10].
• We formally prove the correctness and security of our 3RMN protocol in the universally composable (UC) framework [14], guaranteeing that our 3RMN protocol is secure when composed with other UC-realized primitives.

1) OVERVIEW OF OUR APPROACH
In the design of an RMN, encryption and secret permutation are central primitives used to hide the correspondence between messages and senders. We also begin with a threshold El Gamal encryption [5] owing to its good capabilities, including distributed key generation, joint decryption, and multiplicative homomorphism.
Our first attempt at a round-efficient 3RMN protocol is to have each of the mix servers shuffle the input ciphertexts from all senders and send the resulting list to the receivers without re-encrypting the ciphertexts in a cascade manner. However, after decrypting all lists, the input messages are duplicated n s times, which is obviously undesirable. Even in a case in which decrypting one of the n s lists is allowed, it is TABLE 1. Complexity comparison. Here S: sender, M: mix server, R: receiver, E: modular exponentiation, aG q : a elements in G q , n s : the number of users, n m : the number of mix servers,ñ m : the number of corrupt mix servers, : conditionally satified, ×: not satisfied, and : satisfied.  a i indicates the i -th additive share of a and means an ElGamal ciphertext of a. By ⇒, we mean that a sender transmits its i -th share to the i -th mix server.
ambiguous to determine which of the n s lists of ciphertexts should be chosen for the decryption stage.
Keeping only this structure, our second attempt is to remove useless duplications. To this end, we introduce secret sharing and make the sender split the input message into a set of shares before encrypting it. Then, the mix servers shuffle the list of ciphertexts as before, but each ciphertext carries its shares rather than the message itself. However, after decrypting them, there is no efficient way to restore the original messages.
To fix this problem, we make use of a unique padding method. More specifically, the sender concatenates random padding to every share of its message. This is the prototype of our round-efficient 3RMN protocol, which is depicted in Figure 1. In what follows, we give an example to show a key idea to achieve a constant round RMN protocol.

2) A TOY EXAMPLE
The example considers just three senders and four mix servers since the receivers are the same as those of existing RMN solutions.
First, the senders encrypt additive shares of their message but not the message itself. For example, the 1st sender begins with writing her message a into four shares a = ⊕ 4 i=1 a i where 4 indicates the number of mix servers. Then for each i ∈ {1, . . . , 4}, encrypt and send each of shares a i to the counterpart mix server M i .
Next, each mix server just mixes a list of encrypted shares by applying re-randomization and a private permutation without communicating other mix servers. The remaining steps are the same as the conventional RMN protocols.

D. LIMITATIONS
As an unavoidable tradeoff between efficiency measures, our approach increases the overhead of computation and communication costs. As discussed above, since the senders transmit ciphertexts as many as the number of mix servers, they have to invoke the ElGamal encryption algorithm n m times more than the classical RMN protocol. The computation and communication costs on the side of the mix servers are the same as before. Moreover, when the number of input ciphertexts increases by n m times, the overhead of the receivers grows at the same rate.
Thus, when deploying our RMN protocol in a real-world application, one needs to identify the main bottleneck of the application. If the bottleneck is heavy computation such as modular exponentiation in an algebraic group of large size, our solution is not a good choice. On the other hand, when the bottleneck is network latency due to narrow bandwidth VOLUME 10, 2022 and slow transmission time, our solution is expected to have a better execution time than existing RMN protocols.

E. RELATED WORK ON RMNs
The re-encryption mix-net was first developed by Park et al. in [15] to fix the drawbacks of the decryption mix-net [4] and the hybrid mix-net [16]. See [17], [18] for a comprehensive survey of mix-nets. Since Park et al.'s proposal, much research has focused on RMNs. In a classical RMN, a sender S i only has to compute a single encryption for all the mix servers as ElG.E( pk, m i , r i ), where ElG.E(·, ·, ·) is the El Gamal public key cryptosystem under the public key pk used to encrypt m i with a randomizer r i . In particular, since no predefined order of mix servers is required for the RMN, any mix server M j can compute ElG.E( pk, m i , r i + ρ j ) on the S i input, where ρ j is a randomizer of M j for re-encryption of the S i input. After the list of inputs is re-encrypted and permuted, a mix server M j broadcasts the mixed list to the remaining mix servers for further mixing. The mixing stage ends at the last mix server M n m , where n m is the number of mix servers. Then the group of receivers may perform a joint decryption stage to output a set of permuted messages. We would like to emphasize that in the RMN design, the mix servers do not have to share the private key. Instead, the public and private keys can be those of the receivers, where the public key pk is known to the senders and the mix servers. This type of design is widely used in applications such as e-voting, where a set of authorities receives the mix-net output.
One of the weaknesses of the classical RMN is that to support multiple receivers, an additional stage to share the private key is needed. This drawback is addressed with an improved variant, called universal re-encryption mix-net, proposed by Golle et al. in [10]. In this RMN, the sender S i broadcasts two El Gamal ciphertexts, one containing the plaintext message m i and the other containing the public key of the receiver used to encrypt m i , i.e., ElG.E( pk, m i , r i ) ElG.E( pk, 1, γ i ). The remaining n m − 1 mix servers repeat the re-encryption operation with different randomizers. However, the receiver should perform an exhaustive search on every output list from the mix servers received for possible plaintext messages encrypted under its public key pk.
Despite various optimization techniques (e.g, see [55], [56]), the basic RMN protocol is inherently inefficient in its operation. For example, Hébant et al. [60] and Killer et al. [61] most recently proposed a quite efficient mixnet scheme; still their round complexity is linear to the number of mix servers. Since Abe observed that unlike the DMN, sequential ordered mixing is not necessary [11] in the case of an RMN, Golle and Juels [12] utilized this observation in the efficient design of an RMN where the mix servers perform mixing in parallel. Hence, the authors called this a parallel mix-net. Such a mix-net enjoys considerable improvement in network latency due to the parallelizing technique. More specifically, each of the mix servers is assigned a random subset of the input list; i.e., each subset contains /n m inputs, where is the size of the list. Then, the mix servers perform the following steps: 1) Each mix server mixes a given subset of size /n m .
2) The mix servers performñ n m rounds of rotations, wherẽ n n m is a threshold parameter less than n m . Here, each rotation involves a modulo operation with n m ; thus, the mix server M j−1 transmits its mixed output list to M j , while M j transfers its mixed output list to M j+1 , and so on. 3) After completingñ n m − 1 rounds, each mix server retains a random fraction 1/n m n m of its outputs and sends equal random portions of the remaining outputs to each of the n m − 1 mix servers. Thus, M j receives n m 2 inputs from each of the remaining mix servers, receiving a total of n m n m 2 = n m inputs. 4) Steps 1 and 2 are repeated. Then, the resulting output from the n m mix servers is the final output. We note that the parallel mix-net requires a total of 2(ñ n m − 1) + 2 = 2ñ n m rounds of mixing. Consequently, the parallel mix-net has O(ñ n m ) round complexity.

1) THE OUTLINE OF THIS PAPER
The rest of the paper is organized as follows: We present the system model, the security assumptions and the adversarial model of our protocol in Section II. Ideal primitives are provided in Section III, followed by the full construction in Section IV. Section V presents a formal analysis. First, Section V-A provides the asymptotic and concrete performance of our proposal, and then the formal security proof is given in Section V-B. Concluding remarks are given in Section VII.

II. MODELS, DEFINITIONS, AND TOOLS
This section mainly aims to present cryptographic primitives and related definitions for the secure design of our RMN protocol. We begin by introducing notation used throughout the paper. We also define the system model and the adversarial model that our construction assumes throughout this paper.
Notation: Let [n] denote the set {1, 2, . . . , n}. Letting v be a vector with elements v = (v 1 , v 2 , . . . , v n ), we use the notation v[i] to index the ith element v i . We use bold uppercase letters such as V to denote matrices and sometimes identify a matrix with its ordered set of column vectors. Thus, we mean by V = (v 1 , v 2 , . . . , v ) an × n matrix, and similarly, V [i, j] means the j-th element v i [j] of the i-th vector. For any integer a, we denote by |a| the length of a in bits. For a finite set R, we let r $ ← − R be an element that is sampled uniformly at random from R.
We use κ to denote the computational security parameter (e.g., κ = 80). A function ν : N → [0, 1] is negligible if it tends toward zero faster than 1/n κ for every fixed constant κ. We then use poly(κ) and negl(κ) to denote unspecified polynomial and negligible functions in κ, respectively. Let X = {X κ } κ∈N and Y = {Y κ } κ∈N be ensembles. Two ensembles X and Y are computationally indistinguishable, denoted by ≡, if for every probabilistic polynomial-time (PPT) algorithm D and for all κ ∈ N, there exists a negligible function negl such that

A. MODELS
In this section, we formally describe the target system model and the adversary model we consider in this work, as well as our design goals.

1) SYSTEM MODEL
We follow the three-party system model for the re-encryption mix-net specified by Haines and Müller [18]. The system model consists of three participants: senders, mix servers, and receivers, assuming a publicly append-only bulletin board (PBB). We note that in [18], the authors refer to receivers as trustees. Each sender, denoted by S i∈[n s ] with n s ≥ 2, owns an original input message m i . Let n m be the number of mix servers, and let M j∈[n m ] , with n m ≥ 2, denote a mix server. Receivers are dedicated servers that jointly decrypt a permuted list of original messages.
A round is a duration during which mix servers locally perform mix operations without interacting with other mix servers (or senders). At the end of a round, mix servers may exchange a list of encryptions. From a PBB, we assume that there is a broadcast channel whereby users send messages to all other users in a single round.

2) THREAT MODEL
We need to restrict the adversary, simply because if all parties in a protocol are corrupted, no protocol is secure. Thus, we limit the power of the adversary in terms of how many parties it can corrupt as well as when they are corrupted.
Our work disallows an adversary from corrupting more than half of the mix servers; i.e., more than half of the players in the mix server type are honest. We consider static corruption; i.e., the adversary selects which party to corrupt before the protocol starts. However, corrupted parties are active adversaries who may refuse to follow the protocol's instructions. Moreover, it is assumed that there is no collusion between receivers and other entities (senders and mix servers).
Informally, our security guarantee is that the adversary cannot identify any individual message as being from a certain sender. Formal security definitions and guarantees are provided in Sections II-D and V-B, respectively. We prove that our protocol is secure in the UC framework, ensuring a safe composition with other UC protocols. However, we note that a malicious adversary colluding with any receiver can disrupt the protocol. We do not attempt to prevent malicious players from causing the protocol to abort.

B. DEFINITIONS 1) HARDNESS ASSUMPTIONS
Our construction relies on the decisional Diffie-Hellman (DDH) assumptions, which are formalized as follows: Definition 1: We say that the DDH problem is hard relative to G q if, for all PPT algorithms A, there exists a negligible function negl(·) such that as shown in the equation at the bottom of the page, where G q is a group of order q and the probabilities are taken over the choices of g and a, b, c ∈ Z * q . An additional assumption we use is the discrete logarithm (DL) problem, formalized as follows: Definition 2: We say that the DL problem is hard relative to G q if, for all PPT algorithms A, there exists a negligible function negl(·) such that where G q is a group of order q and the probabilities are taken over the choices of g and a ∈ Z * q .

C. CRYPTOGRAPHIC TOOLS
Our construction heavily relies on two cryptographic tools: secret sharing and homomorphic encryption. In addition, some zero-knowledge proof protocols are used for the purpose of verifiability.

1) SECRET SHARING
In [19], Shamir proposed the first ( 1 , 2 )-threshold secret sharing scheme, where the ( 1 , 2 )-threshold means that the original secret m is split into 2 different shares, and with any 1 shares, the original secret can be reconstructed, while any 1 − 1 shares reveal nothing about the secret. Thus, ( , )-threshold secret sharing technology is suitable for our system model because mixing ciphertexts can be viewed as an outsourced protocol with ≥ 2.
As a popular variant of this method, Blakley, in [20], constructed additive secret sharing, which allows a given secret m to be decomposed into a sum of random numbers. In this work, we use an additive -out-of-secret sharing scheme, denoted as -sharing, as follows: To share a value m, one party, as the dealer, chooses random values {r j } j∈[ ] under the constraint that m = ⊕ j=1 r j and distributes − 1 random shares among them to −1 parties. Clearly, these −1 random shares do not reveal anything about m. This approach is much more efficient for computation than Shamir's solution because it does not require expensive polynomial operations such as interpolation and multipoint evaluation. Furthermore, since our construction does not require a series of multiplication on shares, an -secret sharing scheme is quite suitable for our purposes.

2) THRESHOLD HOMOMORPHIC ENCRYPTION
A public-key encryption (PKE) scheme is a triple of PPT algorithms, denoted by (Kg, E, D): • ( pk, sk) ← Kg(1 κ ) takes a security parameter κ ∈ N as input. It outputs a pair of keys (sk, pk). Here, the public key pk also defines a plaintext space M pk , a randomness space R pk , and a ciphertext space C pk .
• e ← E( pk, m, r) takes pk and a plaintext m ∈ M pk as input. It outputs a ciphertext e ∈ C pk . As usual, this VOLUME 10, 2022 process is randomized using a randomizer r ∈ R pk ; however, sometimes we simply write e ← E( pk, m), omitting the randomness r.
• m ← D(sk, e) takes sk and e ∈ C pk as input. It outputs the plaintext m ∈ M pk . We say that a PKE scheme is correct if for any ( pk, sk) ← − Kg(1 κ ) and any m ∈ M pk , we have m = D(sk, E( pk, m)).
We say that a PKE scheme is homomorphic for the binary relations (⊕, ⊗) if for all ( pk, sk) ← Kg(1 κ ), (M pk , ⊕) forms a group and (C pk , ⊗) forms a group and if for all e 1 , e 2 ∈ C pk , D(sk, e 1 ⊗ e 2 ) = D(sk, e 1 ) ⊕ D(sk, e 2 ). Moreover, given a ciphertext e, anyone can produce a different ciphertext e * that carries the same plaintext as e. Therefore, given a homomorphic PKE scheme, we can define the rerandomization algorithm as Re( pk, e; r) := e ⊗ E( pk, 0; r) for the identity 0 ∈ M pk and r ∈ R pk .
Because it is undesirable for only a single party to be able to control the decryption of ciphertexts, a threshold version of a homomorphic PKE scheme needs to be used in a multiparty setting (e.g., [5], [6], [21], [22]). We use a threshold El Gamal cryptosystem due to its computational efficiency. A threshold PKE (TPKE) scheme has a different syntax than the underlying encryption scheme because of the additional requirement. We present the formal syntax of a TPKE scheme, which consists of a quadruple of PPT algorithms.
• (pk, sk) ← TKg(1 κ , n) takes as input a security parameter κ and the number of parties n. It outputs a pair ( pk, sk), where pk is called the public key and sk = (sk 1 , . . . , sk n ) is a vector of n private key shares. A party R i is given the private key share sk i and later uses it to compute a decryption share for a given ciphertext.
• e ← E( pk, m, r). This is the same as the underlying encryption algorithm.
• e i ← TD( pk, sk i , e) takes as input the public key pk, the ciphertext e, and one of the n private key shares sk i ∈ sk. It outputs the decryption share e i of the plaintext or a special symbol ⊥.
) takes as input the public key pk, the ciphertext e, and n decryption shares {e 1 , . . . , e n }.
It outputs a plaintext m or ⊥. We next formally define the notion of semantic security against chosen plaintext attacks (CPAs) [21]. To simplify the notation, we use . . in a black-box manner, and outputs a. For a PPT adversary A, we define the advantage function where O Kg samples ( pk, sk) ← Kg(1 κ ) and b $ ← − {0, 1} and outputs pk, and if |m 0 | = |m 1 |, then O E (m 0 , m 1 ) returns e b ← E( pk, m b ). We say that the homomorphic PKE scheme is semantically secure against a CPA attack (IND-CPA) if for all PPT adversaries A, the advantage adv IND-CPA PKE (A, κ) is a negligible function of κ.

a: AN INSTANTIATION OF HOMOMORPHIC TPKE
Let p and q be large primes such that q|(p − 1); let G q = g be a subgroup of Z * p of order q for a generator g. Because any element (1 =)g ∈ G q generates the group, the discrete logarithm of α ∈ G q with respect to the base g is defined as usual. All computations in the remainder of this paper are modulo p unless otherwise noted. Now, we describe a way to instantiate a threshold El Gamal PKE scheme.
Each party outputs β i = g α i for a random α i $ ← − Z q and sets sk i to sk i = α i . It outputs the public key pk = (pp, β) and the secret key . This takes as input a message m and randomness r $ ← − Z q and outputs the ciphertext e = (g r , mβ r ).

3) ZERO-KNOWLEDGE PROOFS
Our construction exploits zero-knowledge proofs (ZKPs) to ensure correct behavior. In practice, our protocol can be proven correct by using only so-called -protocols, which only need three rounds of interaction [23], [24]. Unfortunately, -protocols are not known to be zero-knowledge, but they satisfy the weaker property of honest-verifier zeroknowledge. This suffices for our purposes, as we can use the Fiat and Shamir heuristic [25] to make these proofs noninteractive. 1 As a consequence, the obtained proofs are indeed zero-knowledge in the random oracle model and consist of only a single message. 2 For convenience, we report the formal definitions of ZKP, proof of knowledge and -protocols in Appendix A.
Over the decades, there has been much work on securely instantiating various ideal ZKP primitives. In particular, Hazay and Lindell [27], and later Hazay and Nissim [28], described how to transform any ZKP protocol compiled from the -protocol into an efficient protocol that is secure in the UC model. In this section, we thus describe only the protocols that are required to achieve verifiability in our RMN protocol. The detailed specifications of relations and ideal ZKP functionalities will be given in Section III-C.
When receiving an encryption, the encryption should be checked to determine whether it has been faithfully generated. Given an instance of a PKE scheme with public key pk, a zero-knowledge proof of plaintext knowledge (ZKPT) allows a prover to prove knowledge of the plaintext m of ciphertext e ∈ E( pk, m) to a verifier. Known efficient ZKPTs for El Gamal PKE schemes using the -protocol have been demonstrated (e.g., [29], [30], [31]).

b: RECEIVER's ZKPs.
On the receiver's side, two things should be confirmed. First, each receiver should show that it owns the private key share sk i of the private key sk. However, the key generation process is not a simple singleton of the ZKP protocol but requires several complicated subprotocols. Thus, we describe distributed key generation (DKG) in terms of the ideal functionality, as shown later in Section III-B (see Functionality 3). Pedersen showed such a DKG protocol for the El Gamal TPKE scheme [32]. A security flaw in Pedersen's DKG protocol was later corrected by Gennaro et al. in [33].
The second thing to confirm is strongly connected to the distributed decryption of the El Gamal TPKE scheme. Each receiver should prove that it correctly runs the threshold decryption algorithm without reconstructing the private key. Due to the importance of designing verifiable protocols, there have been many ZKP solutions to this problem (e.g., see [13], [34]).

c: MIX SERVER's ZKPs.
A shuffle is a permutation of a re-encryption of the input ciphertexts. By proving that such a shuffle is correct, a prover can verifiably rearrange a vector of ciphertexts e = (e 1 , e 2 , . . . , e ) into e = (ElG.Re(pk, e π(1) ), . . . , ElG.Re( pk, e π( ) )) without revealing the applied permutation π over [ ]. Groth [35] proposed a very efficient way of proving the correctness of a shuffle of El Gamal encryptions in special honest-verifier 2 The stronger assumption of a random oracle is only made for efficiency reasons. Alternatively, we could employ noninteractive ZKPs in the common random string model [26] to obtain noninteractiveness. In principle, our security proof also works in the standard model by utilizing interactive ZKPs. zero-knowledge proofs. Indeed, there have been many solutions for this problem [36], [37], [38], [39], [40], [41].

D. THREE-PARTY RE-ENCRYPTION MIX-NET
Here, we present the ideal functionality of mix-net. In the ideal model, the type of mix-net does not matter; however, for our purposes, the ideal functionality of mix-net uses three distinct parties: senders, mix servers and receivers.
By (P : message), we mean that message was received on a player (e.g., sender) P's input port via the environment Z.
Functionality 1 (Three-Party Mix-net): Let n s , n m , n r be positive integers and t ≤ n r be a threshold value. The ideal functionality for a three-party mix-net, denoted by F 3RMN , running with senders S 1 , . . . , S n s , mix servers M 1 , . . . , M n m , receivers R 1 , . . . , R n r , and a simulator S, proceeds as follows: Output, L)} k∈[n r ] to Z. In the application of electronic voting, m i is the secret ballot of voter S i . Thus, the secret message m i is known only to S i . Whereas in a conventional RMN protocol, |L j | = 1, our RMN protocol sets |L j | = n m and |e i | > 1, as will be seen.

1) SECURITY OF A THREE-PARTY RMN
We define security using the UC framework. The UC framework is quite general and complex, and it is difficult to describe concisely. For reasons of parsimony, we thus omit a review of the UC security framework. For an in-depth discussion, we refer the reader to [14] and [42].
Roughly, the crux of the UC framework consists of the real (world) model, ideal (world) model, and a set of distinct hybrid models. The respective adversary in each model may corrupt a subset of the participants. In the real model, the parties execute a protocol in a certain environment Z in which there is an adversary A and ideal interaction. In the ideal-world model, all parties send their inputs to an ideal functionality F (i.e., a trusted third party) to implement the protocol completely and truly. The parties in the ideal model forward any input to F. A protocol in the ideal model is trivial and produces any output from F as output. Note that an ideal functionality is considered secure by definition. Furthermore, for the purpose of a seamless transition from the real model to the ideal model, various hybrid models are needed. Thus, a protocol running in the hybrid model has access to two or more ideal functionalities.
The definition of security relies on the simulation paradigm. Concretely, a protocol is said to securely realize an ideal functionality if for all real-world adversaries in the real model, there is an ideal adversary (i.e., a simulator) in the ideal model that has the same advantage. In particular, because the definition of security allows the secure composition of protocols, given a protocol that is secure in a hybrid model and protocols that securely realize all ideal functionalities in use, we can trivially construct a secure protocol in the real model.
We will describe in the next section all ideal functionalities for our construction.

III. IDEAL FUNCTIONALITIES FOR THREE-PARTY MIX-NETS
In this section, we formally describe ideal functionalities composed with the main protocol. We inherit some of the ideal functionalities specified by Wikström [43]. However, because our construction is different in the type as well as the system model from Wikstroöm's mix-net, we need to modify some ideal functionalities.
We start by defining the ideal PBB functionality with few modifications.

A. PBB FUNCTIONALITY
A PBB plays a particularly important role in our construction because our protocol extensively uses an authenticated broadcast channel. Assuming the setting of an honest majority with passive security, where more than half of the parties are honest, a PBB can be securely instantiated (see [44]).
Functionality 2 (PBB): The ideal PBB functionality, denoted by F PBB , runs with parties P 1 , . . . , P k and a simulator S.

1) F PBB creates a table indexed on positive integers and
initializes an index t = 1. 2) On receiving (P i : Write, m i ) from the environment Z, (P i , m i ) is stored in the table at the index t, (S : Write, t, P i , m i ) is sent to Z, and t = t + 1 is set. 3) On receiving (P j : Read, t) from the environment Z, hand (S : P j , Read, t, P i , m i ) and (P j : Otherwise, hand (S : P j , NoRead, t) and (P j : NoRead, t) to Z.
The lemma below states that a PBB can be securely realized, assuming that more than half of the parties are honest.
Lemma 1 (Goldwasser and Lindell [44]): There exists a protocol PBB that securely realizes the ideal functionality F PBB in the setting in which more than half of the parties are honest.

B. DKG FUNCTIONALITY
We present the ideal functionality for key generation in a distributed manner for the El Gamal TPKE scheme.
2) For each k ∈ [n r ], receive (R k : SKShares, α k , β k ) such that α k ∈ Z q and β k = g α k ∈ G q , and set As discussed in Section II-C2, for the El Gamal TPKE cryptosystem, Gennaro et al. [33] suggest a secure multiparty protocol for realizing this functionality. Conventionally, we omit the public parameter pp during key generation.

C. ZKP FUNCTIONALITY
As mentioned above, our protocol requires three idealized ZKP protocols, more precisely, zero-knowledge proof of knowledge (ZPK) protocols. From now on, we use ZPK in place of ZKP, unless explicitly stated otherwise. For consistency of representation, we define the ideal functionality for these ZPK protocols following Canetti et al. [45]. Since this functionality takes as a parameter a relation R, we present the ideal ZPK functionality and then present three relations for the functionalities used in constructing our RMN protocol.
Functionality 4 (ZPK): Let L be a language given by a relation R. The ideal functionality, denoted by F R L ZPK , for a zero-knowledge proof of knowledge of a witness ω to a statement x ∈ L, running with a prover P and a verifier V , proceeds as follows: 1) The functionality has an empty table.
2) On receiving (P : Prove, x, ω) from Z, store ω in the table under the index (P, x) and send (S : P, Prove, x, R(x, ω)) to Z. Discard all further messages from P. 3) On receiving (V : Verify, P, x), read ω by the tag (P, x) (the empty string if no witness is found), and hand (S : V , Accept, P, x, R(x, ω)) and (V : Accept, P, R(x, ω)) to Z. The first relation we describe is a ZPK of the plaintext message m given a ciphertext message e = (u, v), where u = g r , v = mβ r . We formally define the relation R PT below. As mentioned above, well-known examples of idealized ZPK protocols of plaintext messages include [29], [46]. 4 × Z * q as (g, β, u, v), r ∈ R PT only if r = log g u. 91404 VOLUME 10, 2022 We remark that the pair (β, v) appearing in the definition is not explicitly used, but we keep it for compatibility with previous methods.

Definition 3 (Knowledge of Plaintext): Define a relation
The second relation for our purposes is a ZPK protocol of correct decryption, where, given a ciphertext e = (u, v), a receiver R i broadcasts d i = u α i so that log g β i = log u d i . The formal definition is given below.
One can view the relation R CD as an ideal counterpart to the protocol shown by Cramer et al. [31]. In our protocol, the receiver R i holds e = (u, v), d i and α i such that d i = u α i , and β i is a public component of pk.
Last, the shuffle relation is defined formally. More specifically, the shuffle relation used in the RMN corresponds to a correct permutation and re-encryption of a list of El Gamal ciphertexts. This relation can be treated as an ideal counterpart to the protocols given by Groth [35], [47]. We continue to define the relation R CS .

Definition 5 (Knowledge of Correct Shuffle): Let N be the set of permutations on [N ] for an integer N
In our protocol, each mix server M j has a permutation π $ ← − N and a set of randomnesses {r 1 , . . . , r N } $ ← − (Z * q ) N . We use F R PT ZPK to denote an ideal primitive of a ZPK protocol for the relation R PT , i.e., zero-knowledge proof of plaintext knowledge. With a similar purpose, we will use two additional pieces of notation F In what follows, we present our main protocol. Our description consists of an overview and the main protocol.

IV. OUR CONSTRUCTION
In this section, we develop the main protocol for the threeparty re-encryption mix (3RMN). First, we present our basic idea to address the round efficiency problem in 3RMN. We then give all the design details of our 3RMN protocol.

A. OVERVIEW
For clarity, we first present our basic 3RMN protocol, hiding the details. Similar to existing RMN protocols, our RMN protocol requires a TPKE with the homomorphic property. However, the main tool that allows us to improve round efficiency is secret sharing. As discussed in the introduction, by encrypting shares of the message rather than a plaintext message itself, mix servers can avoid mixing in a cascade manner.
We focus on showing operational differences from existing RMN protocols on each entity.

1) KEY GENERATION
In this subprotocol, the public key that senders and mix servers later use is generated as in existing RMN protocols. The main difference is that we explicitly have receivers jointly create the key pair. In an e-voting application, the setup procedure will invoke this protocol.

2) MESSAGE ENCRYPTION
Let m i be a plaintext message of sender S i . Every known RMN protocol encrypts m i as e i and then sends e i to the mix servers. In contrast, our RMN protocol first splits m i into a set of additive shares { m i j }. Then, each { m i j } is encrypted and sent to the mix servers. This is one of the main characteristics that is different from those of known solutions. We remark that there are additional options for sending the ciphertexts to a set of mix servers regarding the number of ciphertexts and the choice of the target mix server.

3) MIXING
Our protocol also performs a shuffle process that consists of the permutation and re-encryption of ciphertexts given by senders. The important difference is that our protocol performs this process locally without interacting with other mix servers. This is the second main characteristic of our proposal.

4) MESSAGE DECRYPTION
Receivers jointly decrypt a set of ciphertexts and output a set of senders' input messages. Note that since the shares of the input messages have been encrypted, the receivers need to reconstruct all original plaintexts before producing a permuted list of plaintexts. To ensure the reconstruction is correct, during encryption, each sender should encrypt m ij δ i rather than m ij , where δ i is a unique random value.

B. THE PROTOCOL
We now present a 3RMN protocol in the ( ZPK )-hybrid model in which the players utilize an ideal PBB, ideal distributed El Gamal key generation, and ideal ZPK systems for three relations R PT , R CD , and R CS . Our 3RMN is secure as long as a majority of mix servers are honest. Similar to other RMN systems (e.g., [43]), there are no limitations on the number of corrupted senders.
Our 3RMN protocol 3RMN consists of senders S i∈[n s ] , a mix server M j∈[n m ] , and receivers R k∈[n r ] . We assume that all players agree on the public system parameter pp = (G q , g, p, q) and that the public key pk is implicitly regarded as a tuple (pp, β, {β k } n r ). Concretely, our mix-net protocol runs as follows: Sender S i . Each sender S i performs the following: Mix server M j . Each mix server M j performs the following: 1) Wait for (PKShares, {β k } k∈[n r ] ) from F DKg and compute the public key β = k∈[n r ] β k . 2) Form a list L j = {(u ij , v ij )} i∈[n s ] based on the set Receiver R k . Each receiver R k performs the following: 1) Choose α k $ ← − Z * q and send (SKShares, α k , β k ) to

ZPK ; and form the list
and wait for a response (Accept, In particular, the possibility that two senders will use the same random value is negligible.

C. FURTHER DISCUSSIONS
We explore possible variants of our 3RMN protocol. We expect that these variants may not only contribute to improving transmission costs but also give an additional option for verifiability.

1) REDUCING TRANSMISSION AND COMPUTATION COSTS
As a trade-off of improving round efficiency, our protocol increases computation and transmission costs. The detailed analysis will be discussed in Section V-A below. First, n m El Gamal ciphertexts are sent to the mix servers. This results in n m invocations of the El Gamal encryption algorithm. Moreover, the receiver receives a list of n s ·n m El Gamal ciphertexts and thus performs n s · n m rounds of the partial decryption and aggregation algorithms in total. In some applications, this computational overhead can be a burden.
One way to reduce such additional overhead in computation and communication costs is for the sender S i to split m i into additive shares less than n m , for example, log n m or √ n m . Say log n m is used. Then, each sender transmits only log n m El Gamal ciphertexts, and thus the overhead on the receiver side reduces to n s log n m with respect to the computation and communication costs. Because n m n s , such a design choice can be useful in improving the practical performance of our 3RMN protocol.
We have another option for addressing this efficiency problem. Thus far, every sender has created the same number of additive shares from its plaintext message. However, there is an alternative in which each sender can choose a threshold value of additive shares depending on its circumstances. Thus, a sender that is restricted in computational resources can choose a smaller number of additive shares than resourcerich senders.

2) VERSATILITY OF RANDOM PADDING δ i
An additional benefit of our approach is that δ i , which was originally padded to recover the plaintext message m i , can ensure the integrity of m i . Specifically, after each receiver restores a permutation of plaintext messages, {m 1 , . . . , m n s }, it can record {(m 1 , δ 1 ), . . . , (m n s , δ n s )} on the PBBs. Then, each sender may later check whether her random padding is correctly posted on the PBB. Basically, since the El Gamal encryption scheme is not nonmalleable [48], malicious mix servers can modify the plaintexts embedded in El Gamal ciphertexts. 3 The uniqueness of δ i , which is only known to the sender S i , makes it infeasible for mix servers, given a ciphertext, to create another ciphertext with a related plaintext. This does not mean that our protocol can single out misbehaving mix servers. Instead, our technique can be considered a lightweight solution to prevent mix servers from maliciously performing homomorphic operations on ciphertexts.

V. THEORETICAL EVALUATION
We provide a theoretical analysis of our 3RMN protocol to evaluate its computation, communication, and, more importantly, round efficiency. Then, we analyze the security of our solution.

A. COMPLEXITY ANALYSIS
We first recall the parameters below. Let n s be the number of senders, n m be the number of mix servers, and n r be the number of receivers. In the computation and communication analysis, we focus on the most expensive operations (i.e., modular exponentiation in G q ) in each procedure. In addition, |Z * q | represents the bit length of an element in Z * q , and |G q | is the bit length of an element in G q .

1) ROUND COMPLEXITY
It is quite clear that our 3RMN protocol achieves constant rounds in the number of players. More specifically, each sender broadcasts its El Gamal ciphertexts to mix servers through a PBB. The mix servers output a list of permuted and re-encrypted El Gamal ciphertexts in a broadcast manner to receivers. The group decryption on the receivers' side is somewhat involved. Suppose that receiver R k has a list of El Gamal ciphertexts E = (e 1 , . . . , e n m ), where each component e j∈[n m ] is also a vector of El Gamal ciphertexts. To decrypt E, first, R k partially decrypts E into D under its private key share α k and broadcasts D to the set of receivers through the PBB. At the same time, R k reads the other receivers' broadcasted El Gamal lists. Then, R k recovers a list of plaintext messages M = (m 1 , . . . , m n m ) by simply aggregating counterpart El Gamal ciphertexts. Even if, due to transmission delay among the receivers, some receivers may have to wait to read lists of ciphertexts, the group decryption by the receivers incurs only a constant number of rounds (for details, see [49]). Consequently, our protocol has O(1) round complexity in the number of players. We note that all defined idealized primitives work in a noninteractive manner, so the round numbers consumed in these protocols are also constant. From our explanation thus far, we therefore obtain the following: Proposition 1: The three-party RMN protocol 3RMN presented in Section IV-B requires O(1) round complexity in the number of players, assuming a broadcast channel.
Remark: We should note that allowing a broadcast channel does not imply that we can obtain all n m re-encryptions for a ciphertext at one time. The reason is that each mix server needs to wait for a re-encryption of n m − 1 ciphertexts from all other mix servers before it can broadcast its re-encryption on the PBB. In conclusion, this type of re-encryption requires O(n m ) rounds. See the definition of 'round' in Section II-A.

2) COMPUTATIONAL COMPLEXITY
We next calculate the amounts of computation needed to complete our 3RMN protocol and represent them in terms of asymptotic complexity. We count only the number of modular exponentiations used in the main protocol. In fact, all exponentiations for ZPK subprocedures are asymptotically dominated by those of receivers, as analyzed below.
Each sender S i first generates a set of additive shares and encrypts each of them. Let n m be the number of additive shares for the message m i . Then, since n m El Gamal ciphertexts are computed, in total, 2n m exponentiations in G q are required. The computational cost for executing n m n m -secret sharing is quite small and is omitted. As the mix server performs only the El Gamal re-encryption algorithm, it computes two exponentiations in G q . Each mix server has an El Gamal ciphertext list of size n s . The total number of exponentiations in G q is 2n s . Similarly, each receiver processes a ciphertext list of size n m n s ; thus, the total number of exponentiations is n m n s .
As a consequence, the total computation amount is 2n s n m + 2n s n m + n r (n m n s ) = n s n m (n r + 4), and thus our protocol requires in total O(n s n m n r ) computations, omitting the computational costs of computing all idealized primitives, which contribute to only a constant factor in big-O notation.

3) COMMUNICATION COMPLEXITY
We measure the communication costs for our protocol by counting the number of El Gamal ciphertexts communicated among players. We do not count the transmission costs involved in all subprotocols for the same reason as above.
The sender S i broadcasts n m El Gamal ciphertexts; thus, the total number of transmissions is 2n m elements in G q (i.e., 2n m |G q | bits). Each mix server M j sends n s El Gamal ciphertexts. The total number of transmissions is therefore 2n s |G q | bits. Last, each receiver broadcasts n s n m tuples consisting of an El Gamal ciphertext together with the corresponding partial decryption d • ij . Hence, it sends 3n s n m elements in G q and thus 3n s n m |G q | bits in total.
The total communication costs of our protocol amount to n s · (2n m ) + n m · (2n s ) + n r (3n s n m ) elements in G q . In conclusion, our protocol requires a communication complexity VOLUME 10, 2022 of 4n s n m + 3n s n m n r = n s n m (3n r + 4) = O(n s n m n r ) in the number of players.

B. SECURITY ANALYSIS
We continue to formally prove the security of our protocol. To do this, we show that for each adversary A in the real model, there is a simulator (i.e., an ideal adversary) S such that if the environment cannot distinguish between the two different interactions the protocol is secure. That is, the information learned by adversary A in the real interaction and the information obtained by the simulator in the ideal interaction are indistinguishable. As a proof, it is only necessary to check whether the developed simulator has the ability to generate messages that are indistinguishable from the real-world interaction messages. Our work depends on the ideal functionalities described in Section III and thus is secure under the simulation paradigm. Proof: Let m i be the message of sender S i for each i ∈ [n s ]. Assume that δ i is padding chosen by S i . As specified in the protocol, S i computes e ij = ElG.E( pk, m ij ) so that m i = ⊕ j∈[n m ] m ij and m ij = m ij δ i . Each mix server M j outputs a shuffled list L j = (e π j (1)j , . . . , e π j (n s )j ) from the senders' ciphertexts, where π j is a private permutation of M j . Here, an El Gamal ciphertext e π j (i)j carries a plaintext m π j (i)j = m π j (i)j δ π j (i) . During the group decryption, each receiver begins with a list of ciphertext lists L j from M j . Say the list is (L 1 , . . . , L n m ). This list can be written in matrix form at the end of group decryption as follows: δ π 1 (1) · · · m π n m (1)n m δ π n m (1) m π 1 (2)1 δ π 1 (2) · · · m π n m (2)n m δ π n m (2) . . . . . . . . . m π 1 (n s )1 δ π 1 (n s ) · · · m π n m (n s )n m δ π n m (n s ) By assumption, because all players behave honestly, receivers can find all shares with the same padding and thus can recover the set of original messages {m 1 , . . . , m n s }. This completes the proof.

Proposition 3 (Security): Our protocol
ZPK )-hybrid model with respect to an adversary that statically corrupts fewer than n m 2 mix servers and fewer than n r 2 receivers, assuming that the DDH assumption in G q holds.
Because our proof is in a hybrid model that assumes the existence of the ideal functionalities used in the protocol description (see Section IV-B), we provide a description of possible protocols to implement the functionalities used by our 3RMN protocol (see Section III). For all ideal functionalities, we assume that the public parameter pp = (G q , g, p, q) used throughout the protocol is publicly known.
We begin with the idealized primitives for the functionality F R PT ZPK . Recall that Goldwasser and Lindell suggest a protocol to realize the ideal functionality for PBB (see Lemma 1). Furthermore, our proof heavily relies on transformer ZPK protocols compiled from -protocols into UCsecure ideal functionalities in the common reference string model, as given by Hazay and Nissim [28]. Thus, because the proofs of Lemmas 2, 3, 4, and 5 can be easily obtained from [28], we omit the details. For notational convenience, we use ElG.(Kg, E, D, Agg) instead of (ElG.Kg, . . .).
Lemma 2: Assume that ElG.(Kg, E, D, Agg) is the semantically secure El Gamal TPKE scheme. The Schnorr protocol in [29] securely realizes the ideal functionality F R PT ZPK in the F PBB hybrid model under the hardness assumption of the DDH problem in G q .
We proceed to describe two other ZPK protocols to prove correct decryption and correct re-encryption shuffles. To begin with, Chaum and Pedersen presented a -protocol to prove knowledge of the equality of discrete logs; accordingly, [28] allows us to have Lemma 3, ensuring a protocol that UC-realizes the ideal functionality for the relation R CD .
Lemma 3: Assume that ElG.(Kg, E, D, Agg) is the semantically secure El Gamal TPKE scheme. The Chaum-Pedersen protocol in [50] securely realizes the ideal functionality F R CD ZPK in the F PBB -hybrid model, assuming that the DDH problem is hard in G q .
The second is the idealization of the re-encryption shuffle ZKP protocol. Similar to Lemma 3, there is a securely realized protocol of the ideal functionality F Finally, we need the lemma below for an idealized El Gamal distributed key generation protocol. Examples using such a UC-secure DKG protocol include Wikström [43].
Lemma 5: Assume that the DL problem is hard in G q . Then, the protocol in [33] securely realizes the ideal functionality F DKg in the F PBB -hybrid model with respect to the honest majority of receivers.
Proving Proposition 3 correct: For better understanding, we first describe a brief overview of the proof and then provide a formal proof by developing a simulator.
Since all messages communicated among players are encrypted by the El Gamal TPKE scheme, which is semantically secure, the adversary cannot distinguish an encryption of 0 by a simulator from a real encryption by an honest player in the real model. Thus, we can simulate the messages of honest players. Furthermore, all messages from corrupt players can be extracted from the counterpart ideal functionality by the simulator; thus, the simulator learns all input messages of corrupt senders, all private keys of corrupt receivers, and all shuffle information of corrupt mix servers. As a result, we can simulate the messages of corrupt players. Therefore, it is easy to show that the protocol 3RMN UCrealizes the ideal functionality F 3RMN by combining all these lemmas. Now, we are ready to formally prove Proposition 3. Recall that all players are assumed to agree on the publicly known protocol parameters pp = (G q , g, p, q).
Proof: We define the simulator S. We fix the PPT environment Z and assume a dummy adversary A. S runs a copy of A and simulates the other players for A's benefit, forwarding messages from Z to its simulated A and back. We note that S has access to the randomness used for every ciphertext of the senders and receivers as it is provided to a proper ZPK functionality (e.g., F R PT ZPK ). Similarly, S knows the private keys for each receiver, as it generates the keys for the honest receivers and the corrupt ones send the private keys to F DKg .
Let I be the index set of honest senders, J be the index set of honest mix servers, and K be the index set of honest receivers. By assumption, |J | ≥ n m 2 and |K | ≥ n r 2 . We describe S by dividing it into two submodules. Roughly, S first extracts information for the corrupt players from the corresponding ideal functionalities and then performs simulated computations for the honest players.
Extraction. 1) S instructs every ZPK functionality to respond to any proof attempt by honest players with b * = 1, which indicates that the proof was correct. 2) During key generation, for each receiver R k , if k ∈ K , then S generates the private key for R k ; otherwise, it recovers the private key for the corrupt receiver using its submission to F DKg . 3) S runs simulated honest senders S i∈I honestly, but since they are not connected to the environment Z, they cannot receive Send commands and so take as input m i = 0. S i∈I submits a list of distinct n m El Gamal ciphertexts of 0. If any sender is corrupted, S submits plaintext messages to F 3RMN as follows: After the adversary has aggregated the corrupted senders' submissions, as it hands them to F R PT ZPK , S learns all plaintext shares m ij for all i ∈ [n s ]\I and sends them to ZPK , S learns the permuted plaintext messages by extracting the permutation π j (j ∈ [n m ]\J ) and the randomness and sends them to F 3RMN . Then, it sends (Mix, M j ) to F 3RMN on behalf of the honest mix servers. 5) S simulates honest receivers R k∈K by making them act as if they had received Recover commands from Z. Since S has already extracted the private keys of corrupt receivers in Step 2 and so can decrypt {L j }, it recovers a set of plaintexts and sends the set to F 3RMN . Then, it submits the Output command on behalf of the honest receivers. We continue to describe the computation activities of the simulator. S waits for F 3RMN to output its result m = {m 1 , . . . , m n s }, recovers it, and delays any messages from F 3RMN to other players. Then, the simulator deviates from running the honest players and ideal functionalities honestly in the following ways: Computations.
6) For honest senders, instead of S i∈I presenting a list of El Gamal encryptions of additive shares to m i , it presents a list of El Gamal encryptions of 0. 7) For honest mix servers, instead of M j∈J presenting a permutation and a re-encryption of El Gamal ciphertexts, it presents an equal-sized list of El Gamal ciphertexts of 0 in lexicographical order. 8) For honest receivers R k∈K , it generates a faked list as follows: For each m i∈I recovered from m, it generates a random padding δ * i and finds m ij such that m i = ⊕ j m ij and m ij = m ij δ * i ; it combines these messages with those extracted from corrupt receivers into a matrix M * , each column of which is sorted lexicographically. Then, we present M * on behalf of the honest receivers. It is quite clear that S runs in polynomial time with respect to the input size. We need to show that Z cannot distinguish with non-negligible probability between the interaction with A in the (F PBB , F DKg , ZPK )hybrid execution and the interaction with S in the ideal execution where S has access to only F 3RMN . At this point, the remaining work is to define sequences of hybrid games that each run Z and produce the output of Z, as well as to prove that there is no PPT algorithm Z that can distinguish between each adjacent pair of hybrid games with nonnegligible probability. We omit this part of the proof since completing hybrid games is extremely tedious and not particularly enlightening.

VI. EXPERIMENTAL EVALUATION
The main goal of this section is to empirically validate the efficiency of our proposal. For this purpose, we have implemented it in C++ together with Golle et al. protocol [10] (see §I-E). We herein refer to our implementation as '' '' and to our implementation of Golle et al.'s protocol as '' '', where the box colors reference the corresponding plot colors in Figures 3 and 4.
Our micro-benchmark tests show that our RMN protocol runs approximately 2.3× faster than our competitor. Overrall execution times in milli-seconds. Here we excluded the key generation time in counting the total execution. The number of players in sender and mix server types is taken the same as n ∈ {5, 6, . . . , 14} but with the prefixed number of receivers (n r = 5 for our protocol and n r = 1 for universal RMN protocol).

A. EXPERIMENTAL SETUP
We used MacBook Pro running macOS Big Sur (11.5.1), equipped with 16GB of 2667MHz DDR4 RAM and 2.6GHz 6-core Intel Core i7, Turbo Boost up to 4.5GHz, with 12MB shared L3 cache. Our code was compiled using Clang-12.0.1 with options -std = c++17 -fPIC -O3 enabled. Our implementations leverage the OpenSSL library (1.1.1m) [57]. All experiments use a random prime p of 2048bit length such that p = 2q + 1 for a prime q. All network operations are implemented using the Boost Asio library [58], which is a cross platform C++ library for network and lowlevel I/O programming.
Each of our experiments measures the wall-clock running times for senders, mix servers, and receivers on a single CPU core. We repeated all experiments for 10 trials, and report the average execution timings across the 10 trials for each type of entities, varying the number of participating players. We set the number of players in senders and mix servers entity types to be the same in the range between 5 to 14 but for simplicity of discussion, we fix n r = 5 for our protocol and n r = 1 for Universal RMN protocol. In practice, the number of senders will be much greater than the number of mix servers, but it is sufficient for the purpose of examining how much the total execution time is improved. Furthermore, because Universal RMN protocol does not consider verifiability in their mixnet, for a fair comparison, we also exclude the ZPK protocols discussed in Sections II-C3 and III.

B. OUR RMN VS. UNIVERSAL RMN
Our first collection of experiments measures the running time for key generation. As mentioned earlier on, the number of receivers in both experiments is fixed by n r = 5 which takes an average of 4.72msec. This means that we run the key generation for each experiment and use the newly generated system parameters to execute our and Universal RMN proto-cols. However, we do not consider the key generation time in counting the total execution time.
Our next set of experiments evaluates the execution time as the number of players increases in the range from 5 to 14. When the total number of senders and mix servers is greater than about 30, our testbed suffered from thermal throttling 4 and thus, we set a maximum of senders and mix servers n s = n m = 14.
The plot of our findings is located in Figure 3. We decompose the total execution time into the running time of each type of entities. We present running time plots for respective entity in Figures 4(a), 4(b), and 4(c). The detailed evaluation about their performance will be provided in the next section. Our finding is consistent with our expectation: Our RMN is faster than Universal RMN protocol for improved round complexity. Our RMN and Universal RMN protocol show comparable performance in the execution time until increasing to n s = n m = 9 (i.e., the performance difference is less than 2×), whereafter our RMN protocol reigns supreme considerably. More concretely, Our RMN protocol runs about 2× faster than Universal RMN protocol.

C. IMPACT OF ROUND EFFICIENCY
In order to highlight the impact of network delay in Universal RMN protocol which requires the linear round complexity, we now decompose the total execution time into the running times of each type of entities (i.e., sender, mix server, and receiver) and compare to our RMN protocol with respect to each sub-total running time.

1) SENDERS' PERFORMANCE
We graphically compare our RMN and Universal RMN protocols in Figure 4(a). As you will see, our protocol shows a trend that the running time of the senders increasingly grows whereas Universal RMN protocol keeps almost constant in the running time. Specifically, in Universal RMN protocol each sender just generates a pair of ElGamal ciphertexts. Thus increasing the number of senders (and mix servers) does not affect their running time. On the other hand, our protocol requires that each sender generates a list of n m ElGmal ciphertexts and thus as the number of mix servers n m increases, the running time of senders also increases. It is worthwhile to note that the running time of senders in our protocol may look like to rely on the number of senders, but as mentioned above, in fact, relies on that of mix servers. This is caused by taking the number of senders as the same as that of mix servers.
One thing to give an attention to, in interpreting the plot in Figure 4(a), is that the maximum value of the y-axis is a quite small quantity compared to the total execution time. In what follows, we compare the performance between our mix servers and our competitor's mix servers.

2) MIX SERVERS' PERFORMANCE
This is the heart of our experimental benchmarking test. As shown in Figure 4(b), we can find that the running time of mix servers in both protocol is reversed, viz., the blue line (our plot) is quite below the red line (Univeral RMN's plot). We can see from this that regarding the performance of mix servers, the running time of our protocol is much faster than that of Universal RMN protocol. In both protocols, the most expensive computation of mix servers is re-encrypting a list of ElGamal ciphertexts. Mix servers in our protocol only need to locally re-encrypt n s ElGamal ciphertexts without any interaction with other mix servers; while in Universal RMN protocol, each of mix servers needs to wait for its all predecessors in a certain order to complete their computation. This is the primary reason that our protocol outperforms Universal RMN protocol.
In particular, the maximum value of the y-axis in Figure 4(b) is much larger than those of Figures 4(b) and 4(c). Therefore, we can conclude that the running time saved by removing the interactions between mix servers is obviously meaningful. In conclusion, although senders and receivers in our protocol run slower than those of Universal RMN protocol, gains by reducing network delay by improving round efficiency make up the losses in their running time.

3) RECEIVERS' PERFORMANCE
Receivers in our protocol need to jointly decrypt n m times as many ElGamal ciphertexts as Universal RMN protocol. More precisely, receivers in our protocol get n m lists of n s ciphertexts while those in Universal RMN protocol just get a list of n s ElGamal ciphertexts. Recall that in our protocol a message m i is split into n m shares and then n m ElGamal ciphertexts are given to each mix server. This makes the performance gap between ours and Universal RMN protocol, which is depicted in Figure 4(c).
As discussed above, Figure 3 shows that improving round efficiency can compensate for even these additional computation overhead caused by receivers in our protocol.

VII. CONCLUSION AND FUTURE WORK
In this paper, we presented a UC-secure round-efficient reencryption mix-net in a three-party setting. Our main tool for achieving UC security is a set of idealized primitives, such as well-studied ZPK toolkits. We applied additive secret sharing to the existing RMN to improve round complexity in an asymptotic sense. Furthermore, we performed a theoretical analysis in terms of computation, communication, and round costs. Finally, we provided a detailed security proof in the UC security model. Future work. In our future work, we will construct and implement a concrete e-voting system based on our 3RMN protocol. Towards this end, we aim to provide a proof-ofconcept implementation of our solution in a modern PC environment.
On the theoretical side, we aim to revise our current protocol so that its computation and communication costs are reduced to at least quasi-linear in the number of parties without sacrificing the round efficiency gain. To achieve this goal, we consider two different approaches: one is a batch technique widely used in the design of efficient cryptographic protocols (e.g., [51], [52]). The other is a round compression compiler. Most recently, Ananth et al. [53] introduced the notion of efficiency-preserving round compression compilers.

APPENDIX A OMITTED DEFINITIONS
We formally define zero-knowledge and knowledge extraction by following [54]. We proceed to provide a definition of a -protocol that constitutes a zero-knowledge proof of a special type.
Zero-knowledge proof of knowledge is a proof system P, V for a language L defined over relation R i.e., L = {x ∃ω : (x, ω) ∈ R}, by which a prover P, knowing witness ω, can prove the validity of a statement, i.e., x ∈ L, to a verifier V . Let (P(ω), V (z, r))(x) be the output of V in interacting with P on the common public statement x. The verifier holds the auxiliary input z and the random tape r, whereas P owns the private witness ω.
Definition 6 (Interactive proof system): A pair of PPT interactive machines (P, V ) is called an interactive proof system for a language L if there exists a negligible function negl(·) such that the following two conditions hold: • (Completeness) An honest prover can always convince the honest verifier of a valid statement x ∈ L. Formally, for every (x, ω) ∈ R, Pr[(P(ω), V )(x) = 1] ≥ 1 − negl(|x|).
• (Soundness) A dishonest prover is unable to make a valid proof for an invalid statement x ∈ L with a high probability. That is, for all (x, ω) ∈ R and for all dishonest PPT prover P * , Pr[(P * (ω), V )(x) = 1] ≤ negl(|x|).
Definition 7 (Zero-knowledge): Let (P, V ) be an interactive proof system for a language L. We say that (P, V ) is computational zero-knowledge if for every PPT interactive machine V * , there exists a PPT algorithm S such that where the left term denotes the output of V * after it interacts with P on the common input x and the right term denotes the output of S on x.
Definition 8 (Knowledge extraction): Let R be a binary relation and τ : N → [0, 1]. We say that an interactive function V is a knowledge verifier for the relation R with knowledge error τ if the following two conditions hold: • (Nontriviality) There exists an interactive machine P such that for every (x, ω) ∈ R, all possible interactions of V with P on the common input x and auxiliary input ω are accepted.
• (Validity with error τ ) There exists a polynomial φ(·) and a probabilistic oracle machine M such that for every interactive function P, every x ∈ L R and every ω, γ ∈ {0, 1} * , every machine M satisfies the following condition: Denote by δ(x, ω, γ ) the probability that the interactive machine V accepts on input x when interacting with the prover specified by P x,ω,γ . If δ(x, ω, γ ) > M(|x|), then, on input x and with access to oracle P x,ω,γ , machine M outputs a solution w ∈ R(x) within an expected number of steps bounded by φ(|x|) δ(x, ω, γ ) − τ (|x|) .
The oracle machine M is called a universal knowledge extractor. Definition 9 ( -protocol): A protocol is a -protocol for relation R if it is a 3-round public-coin protocol and the following requirements hold:

• (Completeness) If P and V follow the protocol on input
x and private input ω to P, where (x, ω) ∈ R, then V always accepts.
• (Special soundness) There exists a polynomial-time algorithm A that, given any x and any pair of accepting transcripts (a, e, z), (a, e , z ) on input x, where e = e , outputs ω such that (x, ω) ∈ R.
• (Special honest-verifier zero knowledge) There exists a PPT algorithm M * such that where M(x, e) denotes the output of M for input x and e and (P(x, ω), V (x, e)) denotes the output transcript of an execution between P and V , where P has input (x, ω), V has input x, and V 's random tape (determining its query) equals e.