Download Oblivious Transfer, Secure Computation - I and more Lecture notes Cryptography and System Security in PDF only on Docsity!
University of Illinois, Urbana Champaign CS 598DK Special Topics in Cryptography
Instructor: Dakshita Khurana Scribe: Sourav Das and Jong Chan Lee Date: September 13, 2019
LECTURE
Oblivious Transfer, Secure Computation - I
6.1 Introduction
In the last lecture we have discussed what Public Key Encryption, Private Key Encryption are. We have also talked about El-Gamal’s public key encryption scheme. In this lecture we will first quickly review construction of El-Gamal’s public key encryption scheme. We then introduce Oblivious Transfer and discuss a construction, prove its security with semi-honest (honest but curios) adversarial model. Finally, I will briefly introduce the idea of Simulation Based Security. NOTE: Unless otherwise stated, from here on we will use pk to denote the public key of a cryptographic system and sk to denote the corresponding secret key. For symmetric key encryption, pk = sk. Also we use m denote the message.
6.2 Preliminaries
El-Gamal Public Key Encryption. Given a cyclic group G of size |G| = q with g as one of its generator. El-Gamal’s Public Key Encryption can be described using three PPT algorithm KeyGen, Encrypt, and Decrypt with the following descriptions.
- KeyGen(1k, r) → x, here sk = x and pk = (g, gx^ = h).
- Encrypt(pk, m, r′) ← (gy^ , mhy^ ) where y ← { 0 , 1 }k^ and chosen according to the ran- domness r′.
- Decrypt(x, ct = (c 1 , c 2 )) → c 2 c− 1 1 , where c− 1 1 is the multiplicative inverse of c 1 in G
Just like any other Public-Key-Encryption (PKE) scheme, we want El-Gamal public key encryption to provide the following guarantees.
- Correctness: ∀k, r, r′, m, Decrypt(x, Encrypt(gx, m, r′)) = m
- Security: (IND-CPA) ∀m 0 , m 1 , (g, h, m 0 hy^ ) ≈c (g, h, m 1 hy^ )
Charlie
Alice Bob
- (^) 1.
Charlie
Alice Bob
Alice Bob(0) (^) Alice Bob(1)
World 0 World 1
Guess (^) Guess
Alice Bob(0) (^) Alice Bob(0)
World 0 World 1
Guess Guess
Alice Bob
Figure 6.1: 1-2 Oblivious Transfer using trusted party
Proof Sketch of El-Gamal scheme’s security. Security of El-Gamal builds upon the underlying argument that Decisional Diffie Helman (DDH) is hard i.e no efficient (poly- nomially bounded) nuPPT adversary can distinguish between (gx, gy^ , gxy^ ) and (gx, gy^ , gz^ ) where x, y, z ← G with more than 12 + negl(k) probability.
6.3 Oblivious Transfer (OT)
Definition 6.1. 1-2 Oblivious Transfer (Informally) Alice and Bob are interested in exe- cuting the following protocol. Alice holds two input x 0 , x 1 ∈ { 0 , 1 }k. Alice wants to send exactly one of its input xb, b ∈ { 0 , 1 } to Bob where Bob holds the bit b. From protocol we seek first, x 1 −b remains hidden from Bob and second, b remains hidden from Alice.
Specifically, Alice with input x ∈ { 0 , 1 }k^ and Bob with input b ∈ { 0 , 1 } wants to partici- pate in a protocol that computes the functions f (x 1 , x 2 , b) = xb and outputs xb to Bob and Alice gets no output. We first demonstrate a protocol to achieve this with the presence of a trusted third party Charlie and then later demonstrate a protocol without Charlie. But before that, I would like to ask, why are we studying oblivious transfer?
Motivation. We demonstrate that, Oblivious Transfer (OT) allows us to compute arbi- trary multi-party computation of arbitrary functions.
1-2 OT using trusted third Party. The protocol in with Charlie as a trusted third party is demonstrated in Figure 6.1 which comprises of the following steps:
- Alice sends its input x 0 , x 1 ∈ { 0 , 1 }k^ to Charlie.
- Bob sends its input b ∈ { 0 , 1 } to Charlie.^1
- Charlie sends back Bob xb and sends nothing to Alice.
Observe that in the presence of a trusted Charlie, the above protocol secure in information theoretic sense. Why?
(^1) Step 1 and 2 are interchangeable.
Alice Bob(0) (^) Alice Bob(0)
Guess Guess
Alice Bob
Figure 6.3: 1-2 Oblivious Transfer without Trusted party.
Definition 6.3. Malicious Adversary (Informal). An adversary is called Byzantine when it can deviate arbitrary from the prescribed protocol. Such deviation include but not limited to aborting during execution of protocol, sending carefully crafted messages to actively extract private input of other parties in the protocol.
Question: Are assumption of Semi-Honest adversary practical? Answer:
- Any protocol for semi-honest adversary can be converted into a protocol with malicious adversary using Zero-knowledge Proofs [].
- Semi-honest adversary captures a scenario where during the protocol participant was honest but got corrupted (or hacked) by an adversary after the protocol was over. In such an attack, the adversary A gets access to the entire transcript of the protocol that the victim observes during the protocol.
For today we will only look at Semi-Honest adversary. Fun fact: Oblivious Transfer is a stronger assumption than Public-Key Encryption. Why? We will give a proof sketch of this argument later in the lecture.
1-2 Oblivious Transfer without Trusted Assumption. We give a specific instantiation of the 1-2 OT using El-Gamal’s public key encryption. However, El-Gamal’s scheme can be replaced by any known public key encryption scheme. Figure 6.3 gives a illustration of the protocol described below:
- With (b, k) as its input, Bob generates skb, pkb using KeyGen(1k). Additionally Bob uniformly randomly samples a group element z 1 −b ← G. Note that, in El-Gamal’s PKE, skb = x, pkb = gx. Finally, Bob sends (zb = pkb, z 1 −b) to Alice.
- With local input x 0 , x 1 and receiving the tuple z 0 , z 1 , Alice computes c 0 = Encrypt(z 0 , x 0 ) and c 1 = Encrypt(z 1 , x 1 ) and sends the tuple (c 0 , c 1 ) to Bob.
- Bob on receiving (c 0 , c 1 ) decrypts cb using skb and successfully gets back xb.
Let’s consider why the above construction guarantees Correctness and Security which are defined as below:
Alice Bob
Alice (^) Bob
Alice Bob(0) Alice Bob(1)
World 0 World 1
Guess Guess
Alice Bob(0) Alice Bob(0)
World 0 World 1
Guess Guess
Alice Bob
Figure 6.4: Receiver’s Security in 1-2 Oblivious Transfer
- Correctness: Bob successfully recovers xb
- Security: (i) Alice learns nothing about Bob’s choice bit b, and (ii) Bob learns no information about x 1 −b except what is revealed by xb. If xb and x 1 −b are chosen independently Bob learns nothing about x 1 −b.
It is easy to observe that the correctness of the protocol is obvious so we will focus on the security. We will first present a game based security and then later prove it using simulation based security.
Receiver’s Security against unbounded Sender. Consider two different world w 0 and w 1 where Bob’s input bit in w 0 (respectively w 1 ) is 0 (respectively 1). Alice participates in a 1-2 OT transfer in one of the world without knowing which world it is. At the end of the protocol, we seek Alice to correctly identify the world with only 12 + negl(k) probability on security parameter k.
Theorem 6.4. In the 1-2 Oblivious Transfer in the Plain-Model construction given above, no efficient honest-but-curios sender does learn the input bit b of the receiver with probability higher than 12 +negl(k) probability. Note that for this specific construction, this theorem holds even for computationally unbounded adversary.
Proof. Since both z 0 , z 1 ∈ G and are public key corresponding to some unique secret key, even a computationally unbounded Alice can’t distinguish between z 0 and z 0 since gx^ ≈u z. Hence the best strategy for Alice is to randomly guess Bob’s input and Alice’s guess will only be correct with probability 12.
Sender’s Security against Computationally bounded Receiver. Just like earlier, consider two world w 0 and w 1 where in world w 0 (respectively w 1 ) sender’s inputs are (x 0 , x 1 ) (respectively (x′ 0 , x′ 1 )) where xb = x′ b and x 1 −b 6 = x′ 1 −b. The receiver participates in one of the world without knowing which it is, with its input bit b and thus gets xb = x′ b. Now at the end of the protocol, we seek the computationally bounded receiver to correctly identify the world he did participate only with 12 + negl(k) for security parameter k.
Theorem 6.5. In the 1-2 Oblivious Transfer in the Plain-Model construction given above, no efficient honest-but-curios receiver will be able to distinguish between world w 0 and w 1 with probability higher than 12 + negl(k) probability.
x y
Alice ⊕ Bob
x ⊕ y
Figure 6.6: Two-Party Computation of the XOR functionality
x
x y
Alice ⊕ Bob
x ⊕ y
Figure 6.7: Trivial Solution Protocol for Two-Party Computation of XOR
Problem 6.6. Two-Party Secure Computation of XOR. Let us consider two separate parties Alice(A) and Bob(B), whom to each other are potentially semi-honest adversaries. Alice is given as input a single bit x ∈ { 0 , 1 }, while Bob is also given a single-bit input y ∈ { 0 , 1 }. Question. Is there a secure protocol through which Bob can obtain the output x ⊕ y (Alice does not have any output), while Alice and Bob learn as close to nothing about each other’s input values as possible?
A simple, obvious protocol comes to mind that solves this problem. We can simply have Alice communicate her input x to Bob and have Bob run the computation (x, y) → x ⊕ y on his own. We illustrate this in Figure 6.7. At first glance, this protocol may seem insecure since it would lead to Bob learning Alice’s input x. It is difficult to come up with a security argument for this scheme under our previous notion of game-based security. However, Bob learning x is an inevitable consequence of the problem setting that arises regardless of what protocol we use to solve this problem. Once Bob obtains the output value x ⊕ y, he can simply combine that with his own input y to compute x = (x ⊕ y) ⊕ y. Thus, Bob being able to figure out x is not a sign that our trivial protocol is insecure; rather the definition of security that applies to such protocols should be flexible enough to tolerate our simple solution.
Alice Bob
F(x, y) G(x, y)
x y
Bob's View
Figure 6.8: Real World Protocol and Bob’s View
6.6 Real-Ideal Model
To reach a notion of security that will help us with the dilemma of the previous section, we first introduce the idea of a comparison between the “real world” and the “ideal world”. First let us define a general version of the two-party secure computation protocol that we actually want to make secure, i.e. the “real world” protocol. For now we will leave out the ‘secure’ part.
Definition 6.7. Real World Protocol. Let us consider two separate parties Alice(A) and Bob(B), whom to each other are potentially semi-honest adversaries. A real world two-party (secure) computation protocol in which Alice and Bob are the participating parties can be summarized as the following:
- Alice and Bob each receive as input some values x and y, respectively, so that neither party knows the other’s input.
- Alice and Bob send each other messages that help with the computation of function- alities F (x, y) (Alice) and G(x, y) (Bob).
- Eventually, Alice outputs F (x, y) and Bob outputs G(x, y), either or both of which can be null if we want Alice or Bob (or both) to not have any output value.
Figure 6.8 is a depiction of how the real world protocol might look.
The ideal world protocol for two party secure computation is a protocol that has the same end goal as the real world protocol, but one that is made much easier thanks to the existence of an ideal trusted third party (TTP; Charlie in our previous discussion in Section 6.3). An ideal world protocol would look something like Figure 6.9 and can be defined as in the following.
Definition 6.8. Ideal World Protocol. Let us consider two separate parties Alice(A) and Bob(B), whom to each other are potentially semi-honest adversaries. In addition let us say that there is a party Charlie(C) that both Alice and Bob can communicate securely with. We assume that Charlie is an ideal trusted third party whom both Alice and Bob can trust their inputs with and who will provide only completely reliable output values to Alice and
Alice
Charlie
x y
F, G
F(x, y) (^) G(x, y)
Simulator
Bob
Figure 6.10: Ideal World Protocol with Simulator
- his input and output values,
- and the (secret) states he holds during the protocol
as Bob’s view of the protocol. We can define the security of the protocol with regard to Bob as the computational indistinguishability of Bob’s view of the real world protocol from Bob’s view of the ideal world protocol. There is a problem to this real/ideal-world-view-based notion of security, however. The ideal world protocol is obviously distinguishable from the real world protocol by the fact that Bob interacts with Charlie and Charlie only, instead of interacting with Alice. Therefore, Bob’s “interface” or Bob’s view of the ideal world protocol and that of the real world protocol can never actually be computationally indistinguishable. Our solution to this is to alter the ideal world protocol so that we can force Bob’s view of it to be indistinguishable from that of the real world protocol. This is achieved via the introduction of the concept of simulation.
6.7 Simulation-Based Security
Let us continue to refer to the situation in which Bob is potentially a semi-honest adversary. A simulator is an algorithm that inserts itself between Bob and the rest of the ideal world protocol and pretends to be real world Alice, interacting with Bob in the exact same way Alice would in the real world protocol. It simulates Alice using only the information that ideal world Bob would know. As a result, given that the real world protocol and the (simulated) ideal world protocol are indistinguishable, Bob should not be able to figure out x in the real world. More specifically, Simulator(1k, r) is an algorithm that takes as input a size k string of 1’s (where k is the security parameter) and some randomness r, and simulates real world Alice. A diagram of how this would look is given in Figure 6.10. One behavior of simulators that differentiates them from a “real world Alice” is that they extract all inputs from the semi-honest adversaries they are dealing with. In our example case, the simulator extracts y from Bob. This is so that the simulator can play the input-output game with Charlie, i.e. give Charlie y and learn G(x, y) in return. It is helpful to think of the simulator as a public algorithm, which Bob should be able to interact with in a manner that is indistinguishable from how he would interact with Alice. The simulator in this case should also be a probabilistic polynomial-time (PPT) Turing machine, and is thus at most as powerful as Bob is. It is customary to think of the simulator
as computationally bounded, even when the semi-honest adversary (Bob) is assumed to be computationally unbounded. There are some exceptions, however, in which the adversary is computationally unbounded, where it may make sense to consider the simulator to be unbounded as well. It is easy to conjure an analogous definition of security for Alice. To sum up the results of what we have discussed so far, we can finally define two- party secure computation protocols using the newly introduced notion of simulation-based security.
Definition 6.9. Two-Party Secure Computation Protocol. Given two potentially semi- honest, or “honest-but-curious” parties Alice(1st) and Bob(2nd), each with inputs x and y, respectively, that are unknown to the other party, a protocol for the two-party computation of a probabilistic polynomial-time functionality F (x, y) is secure if there exists for each ith party (i ∈ { 1 , 2 }) a probabilistic polynomial-time algorithm Simulatori(1k, r) such that the simulated ideal world two-party computation protocol and the original real world protocol are computationally indistinguishable in terms of the view of the ith^ party.
Note that we used the terms ith^ party in the later parts of the definition instead of Alice and Bob. One can infer that this definition can be straightforwardly extended to cases in which 3 or more parties are involved, i.e. it can be generalized to a simulation-based security definition for multi-party computation (MPC). Simulation-based security will be dealt with in more depth in the next lecture.
6.8 Epilogue
Once again recall our claim that a secure oblivious transfer protocol that computes the functionality F ((x 0 , x 1 ), b) = xb in the ”honest-but-curious” adversary model implies our capability to securely compute any arbitrary functionality under the same semi-honest ad- versary assumptions. Question for next class. Why is the existence of a secure oblivious transfer protocol sufficient for us to successfully implement a secure two-party protocol for multiplication (AND)? In other words, can we construct a protocol where Alice, given input x, and Bob, given input y, can interact with each other that Bob can output xy (and Alice outputs nothing) in a way that is secure?fa
Acknowledgement
These scribe notes were prepared by editing a light modification of the template designed by Alexander Sherstov.
