Download Multiparty Secure Computation: Definition and Applications and more Lecture notes Mathematics in PDF only on Docsity!
Multiparty secure computation I: Definition and Honest-But-
Curious to Malicious complier
Wikipedia defines cryptography as “the practice and study of techniques for secure communication in the presence of third par- ties called adversaries”. However, I think a better definition would be: Cryptography is about replacing trust with mathematics.
After all, the reason we work so hard in cryptography is because of a lack of trust. We wouldn’t need encryption if Alice and Bob could be guaranteed that their communication, despite going through wire- less and wired networks controlled and snooped upon by a plethora of entities, would be as reliable as if it has been hand delivered by a letter-carrier as reliable as Patti Whitcomb, as opposed to the nosy Eve who might look in the messages, or the malicious Mallory, who might tamper with them. We wouldn’t need zero knowledge proofs if Vladimir could simply say “trust me Barack, this is an authentic nuke”. We wouldn’t need electronic signatures if we could trust that all software updates are designed to make our devices safer and not, to pick a random example, to turn our phones into surveillance de- vices. Unfortunately, the world we live in is not as ideal, and we need these cryptographic tools. But what is the limit of what we can achieve? Are these examples of encryption, authentication, zero knowledge etc. isolated cases of good fortune, or are they special cases of a more general theory of what is possible in cryptography? It turns out that the latter is the case and there is in fact an extremely general formulation that (in some sense) captures all of the above and much more. This notion is called multiparty secure computation or sometimes secure function evaluation and is the topic of this lecture. We will show (a relaxed version of) what I like to call “the fundamental theorem of cryptography,” namely that under natural computational
Compiled on 11.17.2021 22:
320 an intensive introduction to cryptography
conjectures (in particular the LWE conjecture, as well as the RSA or Factoring assumptions) essentially every cryptographic task can be achieved. This theorem emerged from the 1980’s works of Yao, Goldreich-Micali-Wigderson, and many others. As we’ll see, like the “fundamental theorems” of other fields, this is not a result that closes off the field but rather opens up many other questions. But before we can even state the result, we need to talk about how can we even define security in a general setting.
16.1 IDEAL VS. REAL MODEL SECURITY.
The key notion is that cryptography aims to replace trust. Therefore, we imagine an ideal world where there is some universally trusted party (which cryptographer Silvio Micali likes to denote by Jimmy Carter, but feel free to swap in your own favorite trustworthy per- sonality) that communicates with all participants of the protocol or interaction, including potentially the adversary. We define security by stating that whatever the adversary can achieve in our real world, could have also been achieved in the ideal world. For example, for obtaining secure communication, Alice will send her message to the trusted party, who will then convey it to Bob. The adversary learns nothing about the message’s contents, nor can she change them. In the zero knowledge application, to prove that there exists some secret 𝑥 such that 𝑓(𝑥) = 1 where 𝑓(⋅) is a public function, the prover Alice sends to the trusted party her secret input 𝑥, the trusted party then verifies that 𝑓(𝑥) = 1 and simply sends to Bob the message “the statement is true”. It does not reveal to Bob anything about the secret 𝑥 beyond that. But the paradigm goes well beyond this. For example, second price (or Vickrey) auctions are known as a way to incentivize bidders to bid their true value. In these auctions, every potential buyer sends a sealed bid, and the item goes to the highest bidder, who only needs to pay the price of the second-highest bid. We could imagine a digital version, where buyers send encrypted versions of their bids. The auc- tioneer could announce who the winner is and what was the second largest bid, but could we really trust him to do so faithfully? Perhaps we would want an auction where even the auctioneer doesn’t learn anything about the bids beyond the identity of the winner and the value of the second highest bid? Wouldn’t it be great if there was a trusted party that all bidders could share with their private values, and it would announce the results of the auction but nothing more than that? This could be useful not just in second price auctions but to implement many other mechanisms, especially if you are a Danish sugar beet farmer.
322 an intensive introduction to cryptography
(^4) As a side note, we can avoid this issue if we have an honest majority of players - i.e. if |𝑇 | < 𝑘/2, but this condition does not make sense in the two party setting, where you can only have an honest majority if there is no cheating party.
b. For every 𝑖 ∈ [𝑘], if 𝑖 ∉ 𝑇 (i.e., party 𝑖 is “honest”) then 𝑦𝑖 = 𝑦′𝑖 and otherwise, we let 𝑆 choose 𝑦𝑖.
That is, the protocol is secure if whatever an adversary can gain by taking complete control over the set of parties in 𝑇 , could have been gained by simply using this control to choose particular inputs {𝑥𝑖}𝑖∈𝑇 , run the protocol honestly, and observe the outputs of the functionality. Note that in particular if 𝑇 = ∅ (and hence there is no adversary) then if the parties’ inputs are (𝑥 1 , … , 𝑥𝑘) then their outputs will equal 𝐹 (𝑥 1 , … , 𝑥𝑘).
16.2.2 Allowing for aborts Definition 16.1 above is a little too strong, in the following sense. Con- sider the case that 𝑘 = 2 where there are two parties Alice (Party 1 ) and Bob (Party 2 ) that wish to compute some output 𝐹 (𝑥 1 , 𝑥 2 ). If Bob is controlled by the adversary then he clearly can simply abort the protocol and prevent Alice from computing 𝑦 1. Thus, in this case in the actual execution of the protocol the output 𝑦 1 will be some error message (which we denote by ⊥). But we did not allow this possiblity for the idealized adversary 𝑆: if 1 ∉ 𝑇 then it must be the case that the output 𝑦 1 is equal to 𝑦′ 1 for some (𝑦′ 1 , 𝑦′ 2 ) = 𝐹 (𝑥 1 , 𝑥 2 ). This means that we would be able to distinguish between the output in the real and ideal setting.^4 This motivates the following, slightly more messy definition, that allows for the ability of the adver- sary to abort the execution at any point in time:
Definition 16.2 — MPC with aborts. Let 𝐹 be a 𝑘-party functionality. A secure protocol for 𝐹 is a protocol for 𝑘 parties satisfying that for ev- ery 𝑇 ⊆ [𝑘] and every efficient adversary 𝐴, there exists an efficient “ideal adversary” (i.e., efficient interactive algorithm) 𝑆 such that for every set of inputs {𝑥𝑖}𝑖∈[𝑘]⧵𝑇 the following two distributions are computationally indistinguishable:
- The tuple (𝑦 1 , … , 𝑦𝑘) of outputs of all the parties (both con- trolled and not controlled by the adversary) in an execution of the protocol where 𝐴 controls the parties in 𝑇 and the inputs of the parties not in 𝑇 are given by {𝑥𝑖}𝑖∈[𝑘]⧵𝑇 we denote by 𝑦𝑖 = ⊤ if the 𝑖𝑡ℎ^ party aborted the protocol.
- The tuple (𝑦 1 , … , 𝑦𝑘) that is computed using the following pro- cess:
multiparty secure computation i: definition and honest-but-curious to malicious complier 323
(^5) Actually, if we want to be pedantic, this is what’s known as a zero knowledge argument system since soundness is only guaranteed against efficient provers. However, this distinction is not important in almost all applications. (^6) Our treatment of the input graph 𝐻 is an instance of a general case. While the definition of a function- ality only talks about private inputs, it’s very easy to include public inputs as well. If we want to include some public input 𝑍 we can simply have 𝑍 concate- nated to all the private inputs (and the functionality check that they are all the same, otherwise outputting error or some similar result).
a. We let {𝑥𝑖}𝑖∈𝑇 be chosen by 𝑆, and compute (𝑦 1 ′, … , 𝑦′𝑘) = 𝐹 (𝑥 1 , … , 𝑥𝑘). b. For 𝑖 = 1, … , 𝑘 do the following: ask 𝑆 if it wishes to abort at this stage, and if it doesn’t then the 𝑖𝑡ℎ^ party learns 𝑦′𝑖. If the adversary did abort then we exit the loop at this stage and the parties 𝑖 + 1, … , 𝑘 (regardless if they are honest or malicious) do not learn the corresponding outputs. c. Let 𝑘′^ be the last non-abort stage we reached above. For every 𝑖 ∉ 𝑇 , if 𝑖 ≤ 𝑘′^ then 𝑦𝑖 = 𝑦′𝑖 and if 𝑖 > 𝑘′^ then 𝑦𝑖′ = ⊥. We let the adversary 𝑆 choose {𝑦𝑖}𝑖∈𝑇.
Figure 16.1 : We define security of a protocol imple- menting a functionality 𝐹 by stipulating that for every adversary 𝐴 that controls a subset of the par- ties, 𝐴’s view in an actual execution of the protocol would be indistinguishable from its view in an ideal setting where all the parties send their inputs to an idealized and perfectly trusted party, who then computes the outputs and sends it to each party.
Here are some good exercises to make sure you follow the defini- tion:
- Let 𝐹 be the two party functionality such that 𝐹 (𝐻‖𝐶, 𝐻′) outputs (1, 1) if the graph 𝐻 equals the graph 𝐻′^ and 𝐶 is a Hamiltonian cycle and otherwise outputs (0, 0). Prove that a protocol for com- puting 𝐹 is a zero knowledge proof^5 system for the language of Hamiltonicity.^6
- Let 𝐹 be the 𝑘-party functionality that on inputs 𝑥 1 , … , 𝑥𝑘 ∈ {0, 1} outputs to all parties the majority value of the 𝑥𝑖’s. Then, in any protocol that securely computes 𝐹 , for any adversary that controls less than half of the parties, if at least 𝑛/2 + 1 of the other parties’ in- puts equal 0 , then the adversary will not be able to cause an honest party to output 1.
multiparty secure computation i: definition and honest-but-curious to malicious complier 325
(^8) One example of the kind of issues that can arise is the “grandmasters attack” whereby someone with no knowledge of chess could play two grandmasters simultaneously, relaying their moves to one another and thereby guaranteeing a win in at least one of the games (or a draw in both).
- Setup assumptions: The definition does not assume a trusted third party, but people have studied different setup assumptions includ- ing a public key infrastructure, common reference string, and more.
- Adversarial power: It turns out that under certain conditions, it can be possible to obtain secure multiparty computation with respect to adversaries that have unbounded computational power (so called “information theoretic security”). People have also studies different variants of adversaries including “honest but curious” or “passive adversaries”, as well as “covert” adversaries that only deviate from the protocol if they won’t be caught. Other settings studied limit the adversary’s ability to control parties (e.g., honest majority, smaller fraction of parties or particular patterns of control, adaptive vs static corruption).
- Concurrent compositions: The definition displayed above are for standalone execution which is known not to automatically imply security with respect to concurrent composition , where many copies of the same protocol (or different protocols) could be executed simultaneously. This opens up all sorts of new attacks.^8 See Yehuda Lindell’s thesis (or this updated version) for more. A very general notion known as “UC security” (which stands for “Universally Composable” or maybe “Ultimate Chuck”) has been proposed to achieve security in these settings, though at a price of additional setup assumptions, see here and here.
- Communication: The communication cost for Theorem 16.3 can be proportional to the size of the circuit that computes 𝐹. This can be a very steep cost, especially when computing over large amounts of data. It turns out that we can sometimes avoid this cost using fully homomorphic encryption or other techniques.
- Efficiency vs. generality: While Theorem 16.3 tells us that essen- tially every protocol problem can be solved in principle , its proof will almost never yield a protocol you actually want to run since it has enormous efficiency overhead. The issue of efficiency is the biggest reason why secure multiparty computation has so far not had a great many practical applications. However, researchers have been showing more efficient tailor-made protocols for particular problems of interest, and there has been steady progress in making those results more practical. See the slides and videos from this workshop for more.
Is multiparty secure computation the end of crypto? The notion of secure multiparty computation seems so strong that you might think that once it is achieved, aside from efficiency issues, there is nothing else to
326 an intensive introduction to cryptography
(^9) As we discussed before, bitcoin doesn’t have the notion of accounts but rather what we mean by that for each one of the public keys, the public ledger contains a sufficiently large amount of bitcoins that have been transferred to these keys (in the sense that whomever can sign w.r.t. these keys can transfer the corresponding coins).
be done in cryptography. This is very far from the truth. Multiparty secure computation does give a way to solve a great many problems in the setting where we have arbitrary rounds of interactions and un- bounded communication, but this is far from being always the case. As we mentioned before, interaction can sometimes make a quali- tative difference (when Alice and Bob are separated by time rather than space). As we’ve seen in the discussion of fully homomorphic encryption, there are also other properties, such as compact commu- nication, which are not implied by multiparty secure computation but can make all the difference in contexts such as cloud computing. That said, multiparty secure computation is an extremely general paradigm that does apply to many cryptographic problems.
Further reading: The survey of Lindell and Pinkas gives a good overview of the different variants and security properties considered in the literature, see also Section 7 in this survey of Goldreich. Chapter 6 in Pass and Shelat’s notes is also a good source.
16.3 EXAMPLE: SECOND PRICE AUCTION USING BITCOIN
Suppose we have the following setup: an auctioneer wants to sell some item and run a second-price auction, where each party submits a sealed bid, and the highest bidder gets the item for the price of the second highest bid. However, as mentioned above, the bidders do not want the auctioneer to learn what their bid was, and in general noth- ing else other than the identity of the highest bidder and the value of the second highest bid. Moreover, we might want the payment to be via an electronic currency such as bitcoin, so the auctioneer not only gets the information about the winning bid but an actual self- certifying transaction they can use to get the payment. Here is how we could obtain such a protocol using secure multi- party computation:
- We have 𝑘 parties where the first party is the auctioneer and parties 2, … , 𝑘 are bidders. Let’s assume for simplicity that each party 𝑖 has a public key 𝑣𝑖 that is associated with some bitcoin account.^9 We treat all these keys as the public input.
- The private input of bidder 𝑖 is the value 𝑥𝑖 that it wants to bid as well as the secret key 𝑠𝑖 that corresponds to their public key.
- The functionality only provides an output to the auctioneer, which would be the identity 𝑖 of the winning bidder as well as a valid signature on this bidder transferring 𝑥 bitcoins to the key 𝑣 1 of the auctioneer, where 𝑥 is the value of the second largest valid bid (i.e., 𝑥 equals to the second largest 𝑥𝑗 such that 𝑠𝑗 is indeed the private key corresponding to 𝑣𝑗.)
328 an intensive introduction to cryptography
you could significantly harm security. (For example, it is possible to recover the full RSA key from only 27% of its bits). Here is a better approach, known as secret sharing: To securely share a string 𝑠 ∈ {0, 1}𝑛^ among 𝑘 parties so that any 𝑘 − 1 of them have no information about it, we choose 𝑠 1 , … , 𝑠𝑘−1 at random in {0, 1}𝑛^ and let 𝑠𝑘 = 𝑠 ⊕ 𝑠 1 ⊕ ⋯ 𝑠𝑘−1 (⊕ as usual denotes the XOR operation), and give party 𝑖 the string 𝑠𝑖, which is known as the 𝑖𝑡ℎ share of 𝑠. Note that 𝑠 = 𝑠 1 ⊕ ⋯ ⊕ 𝑠𝑘 and so given all 𝑘 pieces we can reconstruct the key. Clearly the first 𝑘 − 1 parties did not receive any information about 𝑠 (since their shares were generated independent of 𝑠), but the following not-too-hard claim shows that this holds for every set of 𝑘 − 1 parties:
Lemma 16.4 For every 𝑠 ∈ {0, 1}𝑛, and set 𝑇 ⊆ [𝑘] of size 𝑘 − 1, we get exactly the same distribution over (𝑠 1 , … , 𝑠𝑘) as above if we choose 𝑠𝑖 for 𝑖 ∈ 𝑇 at random and set 𝑠𝑡 = 𝑠 ⊕𝑖∈𝑇 𝑠𝑖 where 𝑡 = [𝑘] ⧵ 𝑇.
We leave the proof of Lemma 16.4 as an exercise. Secret sharing solves the problem of protecting the key “at rest” but if we actually want to use the secret key in order to sign or decrypt some message, then it seems we need to collect all the pieces together into one place, which is exactly what we wanted to avoid doing. This is where multiparty secure computation comes into play; we can de- fine a functionality 𝐹 taking public input 𝑚 and secret inputs 𝑠 1 , … , 𝑠𝑘 and producing a signature or decryption of 𝑚. In fact, we can go be- yond that and even have the parties sign or decrypt a message without them knowing what this message is, except that it satisfies some con- ditions. Moreover, secret sharing can be generalized so that a threshold other than 𝑘 is necessary and sufficient to reconstruct the secret (and people have also studied more complicated access patterns). Similarly multiparty secure computation can be used to achieve distributed cryptography with finer access control mechanisms.
16.4 PROVING THE FUNDAMENTAL THEOREM:
We will complete the proof of (a relaxed version of) the fundamental theorem over this lecture and the next one. The proof consists of two phases:
- A protocol for the “honest but curious” case using fully homomor- phic encryption.
- A reduction of the general case into the “honest but curious” case where the adversary follows the protocol precisely but merely attempts to learn some information on top of the output that it is
multiparty secure computation i: definition and honest-but-curious to malicious complier 329
“entitled to” learn. (This reduction is based on zero knowledge proofs and is due to Goldreich, Micali and Wigderson) We note that while fully homomorphic encryption yields a con- ceptually simple approach for the first step, it is not currently the most efficient approach, and rather most practical implementations are based on the technique known as “Yao’s Garbled Ciruits” (see this book or this paper or this survey ) which in turn is based a no- tion known as oblivious transfer which can be thought of as a “baby private information retrieval” (though it preceded the latter notion). We will focus on the case of two parties. The same ideas extend to 𝑘 > 2 parties but with some additional complications.
16.5 MALICIOUS TO HONEST BUT CURIOUS REDUCTION
We start from the second stage. Giving a reduction transforming a protocol in the “honest but curious” setting into a protocol secure in the malicious setting. That is, we will prove the following theorem:
Theorem 16.5 — Honest-but-curious to malicious security compiler. There is a polynomial-time “compiler” 𝐶 such that for every for every 𝑘 party protocol (𝑃 1 , … , 𝑃𝑘) (where all 𝑃𝑖’s are polynomial-time computable potentially randomized strategies), (̃𝑃 1 , … ,̃ 𝑃𝑘) = 𝐶(𝑃 1 , … , 𝑃𝑘) is a 𝑘-tuple polynomial-time computable strategies and moreover if (𝑃 1 , … , 𝑃𝑘) was a protocol for computing some (potentially randomized) functionality 𝐹 secure with respect to honest-but-curious adversaries, then (̃𝑃 1 , … ,̃ 𝑃𝑘) is a protocol for computing the same 𝐹 secure with respect to malicious adversaries.
The remainder of this section is devoted to the proof of Theo- rem 16.5. For ease of notation we will focus on the 𝑘 = 2 case, where there are only two parties (“Alice” and “Bob”) although these tech- niques generalize to arbitrary number of parties 𝑘. Note that a priori, it is not obvious at all that such a compiler should exist. In the “honest but curious” setting we assume the adversary follows the protocol to the letter. Thus a protocol where Alice gives away all her secrets to Bob if he merely asks her to do so politely can be secure in the “honest but curious” setting if Bob’s instructions are not to ask. More seri- ously, it could very well be that Bob has an ability to deviate from the protocol in subtle ways that would be completely undetectable but allow him to learn Alice’s secrets. Any transformation of the protocol to obtain security in the malicious setting will need to rule out such deviations. The main idea is the following: we do the compilation one party at a time - we first transform the protocol so that it will remain se- cure even if Alice tries to cheat, and then transform it so it will remain
multiparty secure computation i: definition and honest-but-curious to malicious complier 331
P Did you stop and think?
The problem is that at every step Alice proves that there exists some input 𝑥 1 that can explain her message but she doesn’t prove that it’s the same input for all messages. If Alice was being truly honest, she should have picked her input once and use it throughout the protocol, and she could not compute the first message according to the input 𝑥 1 and then the third message according to some input 𝑥′ 1 ≠ 𝑥 1. Of course we can’t have Alice reveal the input, as this would violate security. The solution is for Alice to commit in advance to the input. We have seen commitments before, but let us now formally define the notion:
Definition 16.6 — Commitment scheme. A commitment scheme for strings of length ℓ is a two party protocol between the sender and receiver satisfying the following:
- Hiding (sender’s security): For every two sender inputs 𝑥, 𝑥′^ ∈ {0, 1}ℓ, and no matter what efficient strategy the re- ceiver uses, it cannot distinguish between the interaction with the sender when the latter uses 𝑥 as opposed to when it uses 𝑥′.
- Binding (reciever’s security): No matter what (efficient or non efficient) strategy the sender uses, if the reciever follows the pro- tocol then with probability 1 − 𝑛𝑒𝑔𝑙(𝑛), there will exist at most a single string 𝑥 ∈ {0, 1}ℓ^ such that the transcript is consistent with the input 𝑥 and some sender randomness 𝑟.
That is, a commitment is the digital analog to placing a message in a sealed envelope to be opened at a later time. To commit to a message 𝑥 the sender and reciever interact according to the protocol, and to open the commitment the sender simply sends 𝑥 as well as the random coins it used during the commitment phase. The variant we defined above is known as computationally hiding and statistically binding , since the sender’s security is only guaranteed against efficient receivers while the binding property is guaranteed against all senders. There are also statistically hiding and computationally binding commit- ments, though it can be shown that we need to restrict to efficient strategies for at least one of the parties. We have already seen a commitment scheme before (due to Naor): the receiver sends a random 𝑧 ←𝑅 {0, 1}3𝑛^ and the sender commits to a bit 𝑏 by choosing a random 𝑠 ∈ {0, 1}𝑛^ and sending 𝑦 = PRG (𝑠) ⊕ 𝑏𝑧 where PRG ∶ {0, 1}𝑛^ → {0, 1}3𝑛^ is a pseudorandom generator. It’s
332 an intensive introduction to cryptography
(^10) Note that even though we assumed that in the original honest-but-curious protocol Alice used a deterministic strategy, we will transform the protocol into one in which Alice uses a randomized strategy in both the commitment and zero knowledge phases.
a good exercise to verify that it satisfies the above definitions. By running this protocol ℓ times in parallel we can commit to a string of any polynomial length. We can now describe the transformation ensuring the protocol is secure against a malicious Alice in full, for the case that that the original strategy of Alice is deterministic (and hence uses no random coins)
- Initially Alice and Bob engage in a commitment scheme where Alice commits to her input 𝑥 1. Let 𝜏 be the transcript of this com- mitment phase and 𝑟𝑐𝑜𝑚 be the randomness Alice used during it.^10
- For 𝑖 = 1, 2, …: - If 𝑖 is even then Bob sends 𝑚𝑖 to Alice - If 𝑖 is odd then Alice sends 𝑚𝑖 to Bob and then they engage in a zero knowledge proof that there exists 𝑥 1 , 𝑟𝑐𝑜𝑚 such that (1) 𝑥 1 , 𝑟𝑐𝑜𝑚 is consistent with 𝜏 , and (2) 𝑚𝑖 = 𝑓𝑖(𝑥 1 , 𝑚 1 , … , 𝑚𝑖−1). The proof is repeated a sufficient number of times to ensure that if the statement is false then Bob rejects with 1 − 𝑛𝑒𝑔𝑙(𝑛) probability. - If the proof is rejected then Bob aborts the protocol.
We will not prove security but will only sketch it here, see Section 7.3.2 in Goldreich’s survey for a more detailed proof:
- To argue that we maintain security for Alice we use the zero knowl- edge property: we claim that Bob could not learn anything from the zero knowledge proofs precisely because he could have sim- ulated them by himself. We also use the hiding property of the commitment scheme. To prove security formally we need to show that whatever Bob learns in the modified protocol, he could have learned in the original protocol as well. We do this by simulating Bob by replacing the commitment scheme with commitment to some random junk instead of 𝑥 1 and the zero knowledge proofs with their simulated version. The proof of security requires a hy- brid argument, and is again a good exercise to try to do it on your own.
- To argue that we maintain security for Bob we use the binding prop- erty of the commitment scheme as well as the soundness property of the zero knowledge system. Once again for the formal proof we need to show that we could transform any potentially mali- cious strategy for Alice in the modified protocol into an “honest but curious” strategy in the original protocol (also allowing Alice the ability to abort the protocol). It turns out that to do so, it is not
334 an intensive introduction to cryptography
other references listed above as well. In particular, the slides and videos from the Bar Ilan winter school on secure computation and efficiency, as well as the ones from the winter school on advances in practical multiparty computation are great sources for this and related materials.
