Compiling an Honest but Curious Protocol

Transcription

1 6.876/18.46: Advanced Cryptography May 7, 003 Lecture 1: Copiling an Honest but Curious Protocol Scribed by: Jonathan Derryberry 1 Review In previous lectures, the notion of secure ultiparty coputing was developed. The setting is that there are parties, each of which has a private input x 1,...,x. The goal is to copute fx 1,...,x,R) securely, where R is rando coins and securely eans that no party obtains any ore knowledge about other parties private inputs than could be obtained if all coputation were done through a trusted third party. The setting for this proble can be thought of as coputers on a network; personal coputation is private but all interparty counication is up for grabs. In previous lectures, Honest but Curious HBC) security was introduced. In the HBC setting, every party is obliged to follow the protocol, but cannot intentionally forget knowledge that it learns during the execution of the protocol. In other words, all parties are curious, in that they try to find out as uch as possible about the other inputs despite following the protocol. A protocol is secure in the HBC sense if and only if all parties have no new knowledge at the end of the protocol above what they would have learned fro the output of f. Recall the HBC 4 ) oblivious transfer OT) protocol: 1 A p B A R;x 1,x,px 3 ),x 4 x i {0,1} n B [ R p 1 i )] s i i=1,,3,4 A B, where p is a trapdoor perutation, R is a rando n-bit vector, denotes the dot product, i is either x i or px i ) depending on what B sent in the second step of the protocol, and s i represents four different secret bits known to A of which B has selected one to learn. In this case, because B applied p to x 3, B learns the value of s 3. Extending HBC In this lecture, HBC security will be extended to create protocols that are secure even if soe subset of the parties are corrupt as discussed in [GMW87]). In studying the security of these protocols we assue the following 3-1

2 each party has full knowledge of A 1,...,A, the algoriths that parties 1,..., are supposed to use during the coputation of fx 1,...,x,R) good guys only have prior knowledge of their own inputs no bad guy has prior knowledge of any good guy s input or rando coins, which are assued to coe fro nature and to be secret bad guys ay collude as uch as they want between each other, including sharing their inputs Now, to create a protocol that is secure against alicious parties, our strategy has several steps n) 1. Define HBC solution n private). Produce HBC solution see last lecture) 4 ) 3. Produce coputationally HBC OT see the review) 1 4. Copile HBC protocol into a protocol that is secure against alicious adversaries To accoplish the last step, we first observe that each party in the protocol only gets to see the essages that each A i gets and its answers a to the essages. 3 Enforcing Honest Tape Use in a Malicious Environent The first difficulty that arises during copilation is that it is hard to deterine whether each participant is actually using a rando tape, or soe cooked up rando tape that could potentially allow the extraction of extra knowledge. To guard against this, we could add an opening round of counication in which each A i broadcasts coitents Cb A i ),CbA i 1 ),CbA i 3 ),... to the bits on its rando tape. This prevents each A i fro changing its rando tape as the protocol progresses because everyone is coited to their rando tapes and each player knows how the other is supposed to act, given the contents of the tapes. At this point, we note that although this prevents the changing of the rando tape, it does not ensure that the tape is rando to begin with. 3.1 Ensuring the Rando Tape s Randoness To solve this proble, the other parties coit to rando guesses about what the contents of the other parties rando tapes are. For exaple, after A 1 akes coitents 1 ),Cb A 1 Cb A 1 ),... to its rando tape, A akes rando guesses Cg A ),Cg A 1 ),... regarding the contents of A 1 s rando tape, and A 3,...,A follow suit. Next, all of the guesses for each bit are revealed, and the actual value of A 1 s rando tape s first bit is declared to be b 1 g g. Note that if at least one eber of the protocol is honest and akes a rando guess then the first bit of the rando tape is indeed rando. Moreover, note that A 1 has not revealed b 1,so A 1 is the only party to know the value of its 3-

3 rando tape at this point if A 1 is honest. Also, A 1 can provide a ZKP that it is behaving in a anner that corresponds to the coitted rando bits without revealing what they are. One potential proble with this schee for generating the contents of the parties rando tapes is that it ay be possible for a cheating party to old its coitent to correlate to the other coitents. This is a proble. For exaple, if A is able to coit to b A 1 g A g A then the first bit of A 1 s tape could be set to 0 presuably A 1 would have to collude with A for A to be able to reveal). However, there are various solutions to this proble. One solution is to siply have the parties reveal their coitents in the reverse order that they broadcasted their coitents. Thus, a correlating cheater would be unable to decoit because it would not know the value of the bit to which it coitted. Another solution to the proble is to use utually independent coitents, which were addressed in a previous lecture, so that such correlation is coputationally infeasible. 3. Coitting to other Tapes Siilarly, everyone can coit to their inputs and work tapes, so that cheating parties cannot decide to change their inputs idway through the protocol or start with a work tape that is not blank. Also, each party sends a coitent to the final state of its worktape. Note that at this point, all of each participant s coputation has been coitted to. Thus, at the end, if each party A i provides a ZKP that if the other parties guessed the private key to its coitents, then they would be able to verify that A i behaved honestly according to the prespecified algoriths, protocol, and the coitted contents of the tapes assuing starting with the blank tape). Because this is clearly an NP stateent, such a ZKP can be given. 3.3 Ipleenting Counication When counication is to be broadcast to everyone, there is no proble because there is no concern about who overhears it. However, one useful for of counication in the HBC setting is the ability to whisper to other parties so that only one other person hears what you say. This has a natural ipleentation in the alicious setting. Everyone siply announces their public key at the beginning of the protocol. Thus, if A 1 wants to send A a essage in secret, A 1 broadcasts E A ) to everyone. Note that this has two desirable effects. First, A and only A understands what is said. Second, everyone else receives a coitent to the essage, which can be verified as the correct essage using a ZKP. 4 Worries At this point, let us suarize our worries about why this copilation of an HBC protocol ight not work: 1. Are different bits of the tape rando? as long as one player is honest and coits to a rando bit, the XOR akes the bit rando 3-3

4 . Parties ay be able to correlate coitents to their tapes. Could reveal backwards, use utually independent coitents, or require a proof of knowledge of the value coitted to 3. The agree on a rando bit proble. In a coin-toss-over-the-phone schee one person knows the value of the rando bit before the other, and can abort if they do not like the value. This last worry has not been addressed directly. One solution to it is to legislate that aborting the protocol is not allowed. However, this ay pose a proble what if you are on different planets?). 4.1 Dividing the Secret into Shares Another solution to this proble is to divide the secret value of the rando coin into shares so that any group of less than parties has no inforation about what the coin is, but any group of ore than parties does have enough inforation to deterine what the secret is. Shair proposed one way of doing this[s79]. The idea is to create a polynoial of the for 1 Qx) = a x + a 1x + + a 1 x + a 0, where the value of Qx) is taken odulo a prie p >,and a i {0, 1,...,p 1}. Now, let each party A 1,...,A have a secret defined as s 1 = Q1),...,s = Q). Note that knowing of the secrets yields no knowledge about the reaining values because there is one ore degree of freedo in the polynoial. However, note that knowing just one ore secret allows the full reconstruction of the polynoial because there are only + 1 degrees of freedo for the for of the polynoial. How can this schee be used to help us transfor an HBC protocol? Each party sends each other party a share of its own private key at the beginning of the protocol[cgma85]. In other words, party A i sends E A1 Q1)),...,E A Q)), where Q represents the value of A i s private key. Note that this allows each party to decrypt exactly one share of A 1 s private key. Also, note that the correctness of the shares ust also be verified in the beginning of the protocol via any zero knowledge proofs e.g. the NP ZKP: you could guess a private key that corresponds to the public key, and your share would be the share that you received). At the end of the protocol, if soe coalition tries to cheat, all of the good guys get together and break the coalition s private keys by sharing the secrets that they received. Note that this ethod is only effective against coalitions of size or saller, otherwise the coalition can crack the private keys of all of the honest players. References [GMW87] O. Goldreich, S. Micali, and A. Wigderson. How to Play any Mental Gae - A Copleteness There for Protocols with Honest Majority. STOC [S79] A. Shair. How to Share a Secret. Counications of the ACM. Noveber, pp

5 [CGMA85] Chor, Goldwasser, Micali, and Awerbuch. Verifiable Secret Sharing and Achieving Siultaneity in the Presence of faults. Proceedings of FOCS 85. pp