Lecture 19: Verifiable Mix-Net Voting. The Challenges of Verifiable Mix-Net Voting

Transcription

1 6.879 Special Topics in Cryptography Instructors: Ran Canetti April 15, 2004 Lecture 19: Verifiable Mix-Net Voting Scribe: Susan Hohenberger In the last lecture, we described two types of mix-net voting protocols: decryption mixnets and re-encryption mix-nets. Today, we direct our focus to El Gamal based re-encryption mix-nets. The malleability of El Gamal encryptions, a drawback in many applications, is beneficially used to re-encrypt each ciphertext with new randomness without knowledge of the underlying ballot contents. Further, the output of each El Gamal re-encryption mixnet can be publically verified using a well-known protocol for proving the equivalence of two discrete logarithms [CP92] and a few other tricks. Today, we begin to show how a concerned citizen can verify the output of a mix-net server. We also discuss some ways in which a malicious voter might attempt to cheat the system and provide some techniques for discouraging this undesirable behavior. 1 The Challenges of Verifiable Mix-Net Voting Let us briefly recall the key steps in our El Gamal, verifiable mix-net voting protocol, as illustrated in Figure 1. B1 E C1,0 C1,1 #1 #2 #K C1,k DEC V1 Bn E Cn,0 Cn,1 Cn,k Vn Figure 1: A Mix-Net Voting Protocol First, a group of respectable, but mutually distrusting parties (such as the Republican Party, the ACLU, an election official, etc.) jointly carry-on a secure computation protocol to generate an El Gamal keypair of the form (g x, x), where the public key g x is published and the secret key x is known to no one, but can be recreated from a threshold of shares distributed among the parties. Next, ballots B 1... B n are generated by n different voters and encrypted, under g x, to the ciphertexts C 1,0... C n,0 with the help of some (hopefully trustworthy) computing resources. Then the ciphertexts are sent through k mix-net servers, presumably operated by a host of respectable parties with competing interests, such as the Republican, Democratic, and Green Parties. All ciphertexts are posted to a public bulletin board. Once the outputs of the mix-servers are verified to be correct, a threshold of the parties jointly agree to decrypt the ballots and count the vote. 19-1

2 2 Keeping the Voter Honest Any secure voting protocol must defend itself against a host of adversaries. The voter herself may attempt to cheat the system ; that is, behave in ways that defeat the ideals of a voting democracy. One such example, that we discuss in detail in the next lecture, is vote selling. Any valid voting scheme should not allow a person to prove how they voted to a third party. Today, we look at two other problems that could arise during the production of the initial encrypted ballots C 1,0... C n,0. 1. Canceling a vote. Suppose Bob cares nothing about the election, but wishes to thwart Alice s attempt to express her opinion... whatever that opinion is. We say that Bob cancels Alice s vote if, after seeing her encrypted vote C a,0 and without knowledge of how she voted, Bob can generate a ciphertext C b,0 that votes against Alice s preference. For example, if Alice votes yes on issue 23, then we want to prevent Bob from creating an encrypted ballot with the opposite vote (i.e., no on issue 23) without knowing how either he or Alice voted. 2. Copy-cat voting. A similar scenario that we also want to prevent is vote copying. If Alice tells Bob she is voting yes on issue 23 and he decides to vote the way she does, that is fine. But if Alice chooses not to tell Bob how she voted on an issue, then he should not be able to simply copy her vote. (It is not hard to imagine various kinds of voter coercion based on copying.) Both vote canceling and vote copying can be prevented if Bob is forced to prove knowledge of how he is voting; that is, when Bob presents his encrypted ballot C b,0, he must be prepared to give a zero-knowledge proof of knowledge of the plaintext contents of the ballot. 2.1 Proving Knowledge of Plaintext Given an El Gamal ciphertext C = (α, β) = (g t, my t ) under the public key y, a voter can prove knowledge of m (i.e., how they voted) by instead proving knowledge of t. The justification is that the voter could obtain m from C using t. 1 An efficient, 3-round protocol for proving knowledge of t, assuming that gt is public, is as follows: P V s Z q A = g s c c Z q r = s + ct Check that: g r =? Ag tc 1 Shafi Goldwasser and Ran Canetti suggested simply using CCA2-secure Cramer-Shoup [CS03] instead of El Gamal encryption for the ballots, since its non-malleability prevents an adversary from getting a related message in a different ciphertext (assuming that we disallow the exact same ciphertext for two voters). This idea was debated for a while, until it was given up on account of that fact that the Cramer-Shoup secret key might be necessary to verify the output of the mix-nets. One of the core properties that we want from a voting protocol is public verification. 19-2

3 Here the prover P is the voter, possibly working together with the trusted encryption software E in Figure 1, while the verifier V might be an election official. 2.2 Honest Verifier Zero Knowledge The protocol in the previous section is an honest verifier zero knowledge (HVZK) proof of knowledge protocol. An HVZK protocol has a special soundness property: if the verifier gets to see two transcripts that use that same initial commitment from the prover A = g s where the verifier is allowed to use two different challenges c 1, c 2 and receive the responses r 1 = s + c 1 t, r 2 = s + c 2 t, then the verifier may compute t. (Since the verifier knows r 1, r 2, c 1, c 2, he can solve for s and t.) For more examples of HVZK applications, see the work of Jakobsson and Juels [JJ99] and Cramer, Damgard and Schoenmakers [CDS94]. 3 Keeping the Mix-Server Honest A re-encryption mix-server can behave maliciously in two ways: (1) it can attempt to alter the vote count, and (2) it can attempt to destroy voter privacy. In this section, we discuss how to defeat the first adversarial behavior by forcing the mix-server to provide proof that it did not alter the vote count. Destroying voter privacy, by leaking information about the permutation used, is beyond our mathematical ability to solve. It is impossible for an election official to verify that a mix-server did not sell its permuation information to the mafia. Thus, the accuracy of the vote count is computationally secure (DL hard so that mix-server can t fake proofs) while the voters privacy depends on at least one of the mix-servers being honest (i.e., keeping its permutation information secret). Each mix-server takes in k El Gamal ciphertexts C i = (α i, β i ), re-encrypts them, randomly permutes them, and outputs this new sequence of ciphertexts. To prove that it did not alter the vote count, each mix-server must prove that each ballot in the input appears in the output. More formally, each mix-server must prove the following NP statement: π on {1,..., n} nodes, elements s 1,..., s n, i {1,..., n}, C i,0 = (α i,0, β i,0 ) and C π(i),1 = (α π(i),1, β π(i),1 ), s i where α π(i),1 = α i,0 g s i, β π(i),1 = β i,0 y. Since it is an NP statement, it is clear that we can prove this in zero-knowledge [BGG + 88], the question is: how fast? We first consider the following subroutine. 3.1 The Chaum-Pedersen Protocol This section was editted from a gracious donation by Yael Kalai. First, we consider the simpler task of merely proving that one ciphertext is a ret 1 = (α 1, β 1 ) = (g, m 1 y t ) and c 2 = (α 2, β 2 ) = (g u, m 2 y u encryption of another. Let c ) 19-3

4 be any two ciphertexts. Note that c 2 is a re-encryption of c 1 if and only if c 1 and c 2 are both encryptions of the same message. Let m 2 (a 1, a 2, b 1, b 2 ) = (g, y, α 2, β 2 ) = (g, y, g u t, y u t ). α 1 β 1 m 1 Claim 1 The ciphertext c 2 is a re-encryption of c 1 if and only if log a1 (b 1 ) = log a2 (b 2 ). Proof 1 First, we consider the forward implication. If c 2 is a re-encryption of c 1, then m 2 (a 1, a 2, b 1, b 2 ) = (g, y, g u t, m1 y u t ) = (g, y, g u t, y u t ) since m 1 = m 2. Thus, we see that log g (g u t ) = log y (y u t ) = u t. We consider the reverse implication. If log a1 (b 1 ) = log a2 (b 2 ), then c 2 = (α 1 g v, β 1 y v ) for some v Z q, but this term can be factored out of the ciphertext to reveal c 2 = c 1 (g v, y v ), where (g v, y v ) is simply an encryption of 1! Thus, proving that c 2 is a re-encryption of c 1 boils down to proving that log a1 (b 1 ) = log a2 (b 2 ) or in other words that (a 1, a 2, b 1, b 2 ) is a DDH tuple. We can do this by running the Chaum-Pederson protocol [CP92] for proving that a tuple (g, y, w, u) = (g, g x, g r, g rx ) is a DDH tuple. We now describe that procotol: P V s Z q s (a, b) = (g, w s ) c t = s + cr c Z q accept if and only if g t = aw c y t = bu c Here, all that the prover must know is the re-randomization factor r; not the message itself! The above protocol is an honest verifier zero-knowledge proof-of-knowledge (of x) protocol. 3.2 Considering a n n Mix Now that we know how to show that an El Gamal ciphertext c 2 is a re-encryption of a ciphertext c 1, we want to use this to build a n n mix. That is, we want to prove that (c 1,..., c n ) are re-encryptions of (c 1,..., c n ) without revealing the actual correspondence. One naive approach is to have the kth mix-server prove the following NP statement in zero-knowledge: i j such that C i,k C j,k+1 and j i such that C i,k C j,k+1 Unfortunately, an n n mix-server could prove this statement is true and still be cheating. To see this, consider the case where n = 3. Suppose, input to the mix-server, were two votes for Donald Duck and one vote for Minnie Mouse. The output of a malicious mix-server could be one vote for Donald Duck and two votes for Minnie Mouse and the above statement would still be true! 19-4

5 However a quick inspection of the possibilities shows that the above statement is sufficient for a simple 2 2 mix. We will therefore build a general-purpose n n mix out of 2 2 mixes and we will see how to do this next class. References [BGG + 88] Michael Ben-Or, Oded Goldreich, Shafi Goldwasser, Johan Hastad, Joe Kilian, Silvio Micali, and Phillip Rogaway. Everything Provable is Provable in Zero- Knowledge. In Advances in Cryptology - Crypto 88, pages 37 56, [CDS94] [CP92] Ronald Cramer, Ivan Damgard, and Berry Schoenmakers. Proofs of Partial Knowledge and Simplified Design of Witness Hiding Protocols. In Advances in Cryptology - Crypto 94, pages , David Chaum and T.P. Pedersen. Wallet Databases with Observers. In Advances in Cryptology - Crypto 92, pages , [CS03] Ronald Cramer and Victor Shoup. Design and analysis of practical public-key encryption schemes secure against adaptive chosen ciphertext attack. SIAM Journal of Computing, To appear. Available at [JJ99] Markus Jakobsson and Ari Juels. Millimix: Mixing in Small Batches. Technical report,