>> Vinod Vaikuntanathan: Okay. So it's a pleasure to have Manoj Prabhakaran visiting us today. Manoj is a professor at the University of Illinois at Urbana
Champaign. He's done a lot of great work in many different areas in crypto and is probably most well known for his work in multi-party computation. And I guess he'll be speaking about that today.
>> Manoj Prabhakaran: Okay. Thank you. Everybody can hear me? Well, I think the mic is not on or the speaker is not on. But okay. So this is joint work with Yuval Ishai and Eyal Kushilevitz at Technion and Rafail Ostrovsky and Amit
Sahai at UCLA. I should apologize if the slides are too verbose. I made them yesterday night. So hopefully it will be intelligible.
Okay. So let me start by reminding you of Yao's garbled circuit construction for secure multi-party computation. This is construction which allows a party Alice -- it's a two-party setting. Alice can compute F of X,Y where she holds the input F and Bob holds input Y. And it's secure in the sense that Alice learns nothing other than F of X,Y, nothing about Y other than of FX, Y and Bob learns nothing at all about X. Okay?
The garbled circuit construction involves -- the protocol involves the use of an oblivious transfer perimeter. So let's take it as an ideal box right now. Everybody knows what a oblivious transfer is here? Okay. So what Bob does -- this is Bob, that's Alice. What Bob does is compute -- construct a garbled circuit which somehow encodes his input Y and send to it Alice.
Alice in addition picks up some keys of using the oblivious transfers. Bob doesn't know what Alice input does, but he gets keys you know for all possible inputs and
Alice will pick up the appropriate keys based on her input.
Bob doesn't get to know what she picked up because it's oblivious transfer. And once she gets the keys and the garbled circuit she can do a computation and find out exactly F of X, Y and nothing else. I'll come back to this construction later and describe the details more. But I just wanted to show this right now to describe the problems.
And this construction is very nice. It's one of the earliest secure computation protocols. It's very lightweight in some sense, and it uses a pseudorandom generator but uses it if a black-box manner. So it doesn't matter how you implement the PRG, the construction doesn't need to do that, it just acts as PRG in a black-box manner. Okay? In addition to using the oblivious transfer. And there are no other computational assumptions needed.
And if you don't like this oblivious transfer, you can -- as an ideal black box, you can actually implement it using several protocols. If you implement it using a two-round protocol in which Alice will sensor the message and then Bob responds. And all we need is security against passwords in this case. Then what you get is a two-round protocol, a two-round protocol in the sense that Alice first publishes her -- some sort of a code which encodes X. Bob looks at that and

sends a message which involves the second message of the oblivious transfer and the garbled circuit and then Alice can do the computation. Okay?
So once Alice publishes her encoding of X, Bob can transfer F of X, Y to her.
And Bob can do this many times for different Ys if he wants. Okay? That's a setting of Yao's garbled circuit.
One disadvantage of Yao's garbled circuit is that this is secure only assuming the parties follow the protocol honestly. Okay? So security relies on the parties being honest. So then it guarantees that even if they are curious they don't learn anything more.
So our problem that we are looking at, one way to think about it, is to get the same result, get something as got as Yao's garbled circuit and its functionality but something that is securing its active results. Okay? And in doing so, we will pay some -- you know, there will be some cost in terms of extra communication and cryptographic costs so to speak, extra use of pseudorandom generator. But we like to minimize that. And we like to minimize the overhead.
Okay. So a little more formally we define this primitive called NISC or NISC or not NISC, Non-Interactive Secure Computation. It says slash OT to mean this is an NISC given OT. So it's over then on top of an OT channel. Okay?
So here is the description of what an NISC should do. Its functionality -- now, I'm describing the single instance version where Alice wants to compute a perfect
[inaudible] only for, you know, one Y. So she will -- so to the functionality as an ideal functionality, Alice and Bob have her inputs, X and Y that they give to the functionality. And the functionality should return F of X,Y to Alice and nothing to
Bob.
This of course does allow -- there is room for Alice or Bob to abort the computation if they want. But the abort should be independent of the other party's input. Okay? Okay.
That's a functionality. If you want to implement this, we require that your protocol is particularly structure, namely be non-interactive. What exactly do we mean by that?
So there's only one round essentially in which always and Bob will invoke the oblivious transfer. And it's always -- it can invoke several instances so several bits can be transferred. But it always should be done in parallel in the sense that
Alice, in particular, has to -- so Alice will be the receiver in all these instance of oblivious transfer. Alice will have to give her inputs to OT without seeing the output from the other instances of OT. All right? So she essentially gives all her inputs to OT and gets all the outputs. And then she computes locally, okay?
I didn't -- you know, in the previous description I also had Bob sends a message, but that's subsumed by this. You can send the message through oblivious transfer. But if you want to get explicitly allow that Bob can send a message in

addition to this [inaudible] OT. Okay? And at the end of the computation, Alice should get F of X,Y. That's a structure of the protocol.
The security, there is a standard way to define security. We will define -- we will require that this is secure in the sense of universally composable security against active corruption. So that's the main thing for us, it's security against active corruption.
So for NISC/OT you can -- you require security to hold in the OT hybrid model, namely in the ideal world -- sorry, in the world where you define the protocol, you are given an ideal oblivious transfer primitive. Okay? So I won't go into, you know, the details of how you define security. It's fairly standard.
So that's NISC over OT. You could also think about NISC over any functionality
H where the functionality is like OT in the sense that both parties give one short input and just one of the parties, namely Alice, gets the other function. Okay?
Why do we do this? Not just because we can, but we use these kind of things as intermediate primitives for different H, Hs. Okay?
You might wonder what's the point of just doing NISC over OT if you want to implement it in real life whether you get the OT instances. Well, just like we said in the previous slide for Yao, if you have a two-round OT protocol you can replace this OT axis by the two-round protocol and still the composed protocol will be non-interactive in the sense that Alice publishes something and then Bob can respond. Okay?
Do we have such a thing for UC security? We know that all have this construction for oblivious transfer in the CRS hybrid model. Their parties have access to a common random string. Okay? And that's UC secure protocol.
Okay.
So if you have NISC over OT, that's as good as having NISC with just standard set of like common random string. Okay? So in the rest of the talk mostly I will -- my goal will just be to get NISC/OT and if you -- and it gives a clear -- a clean model of defining the problem. Okay? So we will not worry about how to implement the OT itself.
>>: [inaudible].
>> Manoj Prabhakaran: Yes?
>>: You are going to deal with static corruptions.
>> Manoj Prabhakaran: The corruptions are static. They are two parties, and I'll either Alice as corrupt or Bob as corrupt.
>>: The corruption cannot happen --
>> Manoj Prabhakaran: After the protocol.

>>: [inaudible].
[brief talking over].
>> Manoj Prabhakaran: There are not on many steps. I would suspect -- so you are asking if both parties are honest in the beginning and then you corrupt Bob?
>>: Then they see one message and then they decide to corrupt either Alice or
Bob.
>> Manoj Prabhakaran: As in you might want to actually corrupt Bob I would imagine -- Bob has to explain the garbled circuit, that might cause some problems. I'm not entirely sure. I haven't thought of it. Sometimes it does create problems. I'm too sleep deprived to give a sensible answer at this time.
Okay. So since NISC/OT is what we are looking for, I'll just sometimes call it
NISC for avoiding [inaudible] in some slides. Okay. So what are the -- this as we already know is not a new problem in some sense, right? Secure computation has been around for a long time and some of it has been non-interactive. And we are interested in NISC for general functions. By general I mean anything that you can compute in polynomial time. Okay?
So if you are worried about passive adversaries, both parties follow the protocol honestly. On or even if you are worried about Alice being actively corrupt, Alice
-- the receiver is actively corrupt, Yao's garbled circuit is good enough, okay? So the protocol we give for -- I mean the protocol I mentioned in the beginning I said it's secure if you assume passive adversary, passive, semi honest, honest but curious, they all mean the same thing. And I unfortunately use all of them in these slides.
If -- yeah, in that setting, you know, Yao, that's the setting as Yao proved security or Yao's protocol is prone to be secure. But it works without much extra effort, even when only Alice could be actively corrupt, okay?
So there will be no other solution. And if you don't -- you know, as I said before, it's NISC/OT where you can change in the plain model we're implementing OT by a two-round protocol.
Another option which has become recently available is using fully homomorphic encryption. Okay? And it's in some sense much better than using Yao's garbled circuit in the sense that the communication depends only on the size of the inputs, not on the size of the circuit inform computation. So in principal asymptotically that might be a better solution. But as of now, it's still very impractical because the computation involved is too much. Okay?
So these are both, you know, only if you are worried only about passive adversary.
>>: So does that solution [inaudible] one of the parties is --

>> Manoj Prabhakaran: Is actively corrupt?
>>: Is actively corrupt?
>> Manoj Prabhakaran: If Alice is actively corrupt --
>>: Alice a -- who is Alice?
>> Manoj Prabhakaran: Alice is the receiver. So in all my pictures that party gets the output. Okay? So if Alice is corrupt, she will do the -- oh, okay. I'm not
-- I mean, Bob can decrypt and check some macros in there. I don't know. I haven't thought about it. But, yeah, okay. But the point is these are not good enough if you are worried about an active adversary, or even if just Bob could be actively corrupt, okay? Which is our setting.
So what can you do if Bob is actively corrupt? Well, one is you could use a standard cryptographic tool, namely you compile passive secure protocol using a zero knowledge proof and get an active protocol to secure against active corruption. We want it to be non-interactive. No problem. You do have non-interactive zero knowledge. Okay? So this is one option. Bob will not only give the garbled circuit but use an NIZK to prove non-interactive zero knowledge proof to prove that the garbled circuit is constructed correctly.
The trouble with this solution is, one, is that it's expensive. You have to prove a very general statement in zero knowledge. And the other, more qualitative problem is that it ends up using the pseudorandom generator in the non-black box. Why is that? Yao's garbled circuit consists of, you know, use of pseudorandom generator as I make this query -- you know, invoke the pseudorandom generator this input to see that I get that output.
Now, you need to prove all those things in your -- using your NIZK proof. So you need to actually talk about the code of the PRG, right? So that's the qualitative problem an the solution.
Another solution which I'm -- I bet none of you have seen, it's in the full version of the paper of Yuval and Amit. So there are other results in this paper, but one of the results we mention and it's developed in the appendix of the full version if you bother to look at that, is actually a solution for non-interactive secure computation that is secure against active corruption. Okay. So in some sense it's done, the problem I, you know, stated in the beginning has been solved in that result.
But why is that not good enough is that again, it ends up using the PRG in a non-black-box fashion. It does not use zero knowledge proofs in the sense but it
-- if you are familiar with it, it will have some sort of a multi-party computation ahead and this multi-party computation will have the pseudorandom generator inside it. So you end up using the pseudorandom generator in non-black-box way. So that solution is also not good enough for us. Okay. So personally I'll say we do get this right. So before that, before I tell you that we you'll get a

scheme where the PRG is used in black box fashion, you might very well ask maybe you don't need to use the PRG at all.
So this is non-interactive secure computation given oblivious transfer. So we know that given oblivious transfer you don't need any other computational assumption. You can do secure computation. Okay? The catch is we want to do it non-interactively, okay? So we really don't know that this is possible. In principal it's possible that you don't need any other computational assumption to do non-interactive secure computation once you are given this OT black box.
But, you know, we don't know. That's an open problem.
>>: [inaudible] question. So given OT you have pseudorandom generator I can construct --
>> Manoj Prabhakaran: No, what I meant was given the quality functionality of the black box it's an ideal functionality not as a protocol --
>>: Right. So --
>> Manoj Prabhakaran: Against computational unbounded players, you can get non-interactive secure computation.
>>: Right. But assume for a moment that you could do IPS 08 with black box use of PRG.
>> Manoj Prabhakaran: So this -- that's require computational assumption, that
PRG exists. Computationally up bounded the solution won't work.
>>: Okay.
>> Manoj Prabhakaran: Okay? Yeah. So before I switch to question of black box use of PRG, you know, this is another question you should ask. Any -- all this use of PRG is superfluous. It could very well be. At this point we don't know.
It will be good to show an impossibility also there.
What we will do today is to get this non-interactive secure computation on top of
OT using pseudorandom generator as a black box. Okay?
In addition to this feasibility result and our construction is finally efficient in an asymptotic sense, namely if you're evaluating a very large circuit, the -- you know, the overhead is what you worry about is the size of the circuit times some quantity plus some additional quantity. Our worried about the continent that's multiplied to the size of the circuit because you think of the size of the circuit as huge. Okay. So in that setting what we can get is an overhead in, you know, in terms of overhead over Yao's garbled circuit. Which is a polylog of the security parameter. So this kappa is a statistical security parameter, will require security which is two to the minus kappa. Okay. So error in simulation and so forth should be two to the minus kappa.

Then the overhead that we get is polylog kappa. In particular the number of PRG calls that we make, okay, will be only polylog kappa per gate of the circuit.
Okay? Previous solutions needed at least omega K, okay?
>>: Poly is a polynomial multiple [inaudible].
>> Manoj Prabhakaran: Polynomial, the actual polynomial depends on some of the components we use. And I wouldn't exactly know what that polynomial is.
Okay. Yeah. It's highlight to look up those papers or ask my colleagues who wrote those papers about what exactly is the polynomial in that.
So this -- let's take it just as a theoretical, you know, asymptotic improvement.
We also have protocols which I'll mention when we get to it which are asymptotically less efficient but maybe much more practical. Doesn't go through these complicated underlying protocols. Okay.
We also had a relaxed notion of security. I'll tell you what it is in a second. And then we don't even need -- we can get a constant number of PRG calls per gate of the circuit. Okay? Plus some additional, you know, order -- additional poly kappa queries overall. But if the circuit is very large, it will be constant per gate of the circuit.
And one more thing which I'll -- I won't have time to get back to, is I presented all this for single use, right? When Alice just sends her you know one -- encoding of
X1s and she just gets one message from Bob and computes F of X,Y.
You could ask, okay, you know, maybe she wants to compute F of X,Y for different values of Y. So she publishes a kind of public key that encodes her input and then, you know, different Bobs can send her different messages for each of the Ys and Alice can decode F of X,Y for each of those Ys.
Yao's garbled circuit does work in that setting. We could also get something like that except there's a price to pay. And for a few hundred or more of these reusing your public key will grow slightly. Of course it will be trivial to say if public key grows linearly in the number of reuses. I'll just publish different public keys.
Also you're asking what -- you might be wondering what is issue, right? Why --
>>: No, no. [inaudible] issue. But what does growing slightly mean?
>> Manoj Prabhakaran: So instead of kappa you'll need something like kappa plus T, if you only use T times. So it --
>>: But that's linear in T, right? So if you wanted to use it T times --
>> Manoj Prabhakaran: No, no, it won't be kappa times. So if originally doing like some function of kappa it will be now --
>>: Okay. Fine. [inaudible] this number is kappa -- kappa is 112 you could reuse 100 times before you double the cost. Is that a good number?

>> Manoj Prabhakaran: Yeah. I mean, I have no idea, you know, if you implement these things the standard security pattern does it still hold good? But yeah, that is -- so that will be the case, yeah. Okay. So these are the results I want to kind of try and present today, okay, as much as I can. So remember, we are going to get NISC/OT that uses PRG as a black box.
Before I get there, there are something I'll call predicated-abort security.
Sometimes I call it input dependent abort security. So what exactly do I mean by that? It's an intermediate security notion that I, you know, use to bootstrap to get full execute. But it's also used presumably by itself.
So what it says is that the -- Bob can -- so I said Bob can make Alice abort, right?
He can send out garbled circuit -- garbled circuit doesn't sound [inaudible] garbled circuit and Alice has no choice but to abort. That's fine. He is making
Alice abort independent of her input. He doesn't know anything about her input.
But what we will learn predicated about is that he can make the abort depend on
Alice input. He will still not find out anything about Alice's input. He will not -- so he can specify predicate P. He will not find or of P of X equal to one. But if P of
X equal to do one, then Alice will abort. And, otherwise, not.
So if he could find out if Alice aborted, then he will learn this P of X. So it's not a safe thing to do. In particular this one BI UC secure implementation of the original functionality we are interested in. However, you can define our weakened functionality will actually allow Bob to do this, okay? And you could imagine in some settings, especially if it's being used in a bigger protocol where the environment is kind of safe, this could be useful. So that's a notion -- that's an intermediate -- that's a relaxed security notion.
We will use two specific relaxation relaxations in our -- in our constructions. One is called input value disjunction predicate. So I'll use two predicates. One is input value disjunction predicate. So Alice input is a bunch of bits. And I can specify the predicate P can specify a subset of these bits and values for them.
Okay? So you might say X1 equal to zero and X3 equal to one.
If RX are equal will to one, if that disjunction, if X1 equal to zero or X3 equal to one, then the predicate becomes trouble. Okay? So that will be the input value disjunction predicate. Okay? So essentially we allow Bob to guess one of several bits, as many -- not one of -- he can make many guesses about the different bits. If even one of those guesses is correct, Alice is forced to abort, okay? Yeah?
>>: Who picks this predicate --
>> Manoj Prabhakaran: Bob. Bob gets to pick the predicate.
>>: So you design a protocol and then when you improve security, Bob can say, well, you know, I want this information and that --

>> Manoj Prabhakaran: Yes. So assume that they will say you know this is the predicate which I want to make Alice abort. Okay? So the functionality allows arbitrary [inaudible] but value disjunction allows arbitrary predicates of this.
Okay?
Another one, a little more sophisticated is this wire value disjunction predicate.
So here it is just a predicate of Alice's, you know, inputs and just completely specific in terms of inputs. Here we also talk about a circuit that evaluates F of
X,Y, okay? So and what Bob can specify -- so the circuit is fixed by the protocol essentially. What Bob can specify is an input Y for his circuit and a subset of Y is in the circuit and values for those wires. Okay? So not just input wires but arbitrary wires in the middle. So this wire takes value zero or this wire takes value one or this wire value takes value zero and so forth. And if any of those, you know, guesses match, then the predicate is true. Then always will be forced to abort.
You could imagine -- so you might -- just to give you a flavor, it's not really useful
-- you know, maybe Bob can make guesses that are correct, right, maybe it's very easy to guess something about this wire -- some wire in the circuit. That doesn't make it less secure because, you know, if everybody knew that -- if Bob already knew that that wire is going to be zero and he guessed it as zero and forced Alice to abort big deal he could have made Alice abort anyway, all right?
So just bear that in mind. We'll come back to, you know, how to remedy these things and --
>>: [inaudible] it's like one bit of leakage about --
>> Manoj Prabhakaran: Yes.
>>: [inaudible].
>> Manoj Prabhakaran: It's one bit of leakage if you do not want to include this in the functionality but imagine it's one bit of leakage that protocol allows.
Okay. And yeah, as I said, there's an intermittent notion but it's useful -- you could imagine it's useful in settings where the adversary will not learn whether
Alice aborted or not. So all -- that one bit of leak -- let's just say that one bit that's leaked doesn't really reach the adversary because it's signature inside some bigger protocol or because Alice is going to aggregate many executions and she'll take some action, and if only one of the boxes corrupt and the others are good maybe it won't make a difference. Okay?
So there situations where it's useful so we leave it -- we leave it as a -- we give that definition and leave that construction for use for -- that others can not see useful.
Okay. So the construction is kind of very detailed. There are several components to it. So I'll give you the roadmap, and we'll see how far we can get.
Okay. So step one is we will do this thing, the NISC -- so we have NISC/OT,
NISC/OT. We'll construct NISC for OT for just NC0. So NC0 functions are

functions where each output bit depends on running a constant number of input bits. Okay?
And further we will not require full-fledged security, we'll allow this input value disjunction predicated abort, okay? So it should be certainly a simple -- simpler goal, okay. So it's NISC or NISC/OT for NC0 functions with IVD abort. To build that, we use something called a certified OT. It's a perimeter -- you know, simple enough primitive that will be defined. And we'll build this -- we build a NISC for this particular primitive using MPC in the head kind of idea. So try to go over that in detail.
And then you can combine that certified OT NISC with essentially you could think of that also as Yao's garbled circuit instructed on on a semi-honest secure.
Okay? But only for NC0. So you can actually build those things without computational assumption. And combine these two to get the NISC for NC0 with
IVD abort. That will be our first step. I'll go over that in some detail.
And the other step, other, you know, main step -- well, there are multiple things we could do, but they all have the same flavor. What we are going to do is clear
NISC schemes which use some NC0 function, instead of OT they'll use some
NC0 function. So the ideal box will evaluate some NC0 function H, okay, and give the output to Alice.
And the idea is that you could use the original Yao's garbled circuit but you had to kind of make -- make sure that Bob doesn't cheat in that. You will use this
NC0 function to check and verify that Bob created it correctly up to some extent.
Okay?
So that's kind of the idea. And I'll say why it's not that simple. In particular, this
H has to be NC0 and it does not use the PRGs. Okay? As in it doesn't -- it can not use a PRG on a non-black-box manner. So this -- whether this H will be something which cost not touch the PRG. Which makes it hard to actually verify that the construction is correct.
Okay. We have three [inaudible] of that. First one is a very lien variant, okay.
And this is kind of a main variant. It gets only WVD abort. It's wire value disjunction abort. And this one gets full-fledged security but it's only the most efficient one. Okay?
Now, these are in the NISC NC0 model. The next step is to plug in the NISC for
NC0 into these constructions. And you'll get some NISC protocols. Okay? NISC schemes. And it will be such that we will be careful of this so that for instance here you take a NISC NC0 protocol it requests NC0, you know, no error NC0 ideal function, ideal primitive, right? But we are going to plug in some images
IVD abort, okay? So we had to see how that affects the final security. But, you know, it's simple enough to make sure that that will show up the same way after composition. So after composition you can still get only input value disjunction abort. That is in this case.

In the other two cases you abort condition is more generous. So this already allows the WVD abort which is, you know, more generous than IVD abort. So you'll end up with something which gets WVD abort. And here it allows arbitrary predicated abort so you'll end up with a NISC which is arbitrary predicate.
>>: What's the difference between arbitrary predicate abort and WVD abort?
>> Manoj Prabhakaran: So here it's arbitrary predicate of the inputs, here it's wire value disjunction. You can specify a bunch of wires and values for them. In the circuit. In the circuit.
>>: Specify a circuit?
>> Manoj Prabhakaran: Yes. So you could say the protocol comes with a predicate search.
>>: Okay. [inaudible].
>> Manoj Prabhakaran: And that's --
>>: This is for any, essentially any search?
>> Manoj Prabhakaran: Any predicate. Okay? Not just wire value disjunction.
So not just wire value disjunction. So this very limited. It's saying wire value disjunction. It has to say this wire takes zero or that worry takes one or that wire takes zero.
>>: For this particular circuit?
>> Manoj Prabhakaran: The circuit is fixed and --
>>: [inaudible].
>> Manoj Prabhakaran: And problem is not that circuit is -- problem -- okay.
That's one thing that limits it. But also it's not an arbitrary function of the wire values. All right. Then it [inaudible] arbitrary function of the inputs.
And then these two schemes -- this one we leave at [inaudible]. We don't know how to upgrade this to full-fledged security. But it's really lean, okay? This is efficient. These two we will upgrade to full-fledged security. This one, as you can imagine, it has some problem with the input value disjunction by doing some input and coding we can make sure you get full-fledged security.
This one which allows -- you ask questions about the circuit, we want to make sure you don't get much information by asking questions about the circuit so we use essentially a private circuit construction. And make sure that, you know, this is harmless, being able to use wire value disjunction doesn't really help you, you might just as you'll abort independent of the input. And that will be the full-fledged security. Okay? So we have these three constructions. This one is the most asymptotically efficient. And the polylog K factor overhead over Yao

calls for this construction. But that may not be the most efficient one given the things that go into this private circuit construction. So for small circuits that may not be the best thing to do. So might be, you know, you might want to stick with this. This is an order kappa overhead, not polylog kappa. And all these constructions use the PRG in a black-box manner. Okay.
Okay. Now I'll try to, you know, go over as many boxes as I can in the amount of time I have. So I'll start with, you know, trying to build that, right. So you want to build NISC/OT for this NC0 functionalities. Now, here you don't need any computational assumptions, okay? Unconditionally secure constructions are known. We care only about IVD security but even if you wanted full security you would get it.
In particular, long time back Kilian gave a -- you know, construction about how to leave secure multi-party -- two-party computation using OT unconditionally. And it has insighted a protocol which works for NC0 and can be extended to NC1, you know, without any computational assumptions, okay? And it's an non-interactive protocol, okay?
The trouble is it's very inefficient. So we won't use that. But if you just wanted the feasibility sort of black box PRG we could use that. Okay? Kilian's original protocol does in the paper has only IVD abort kind of -- or predicated abort and
IVD abort security. But it can be [inaudible].
>>: Once you have this construction you take a garbled circuit and --
>> Manoj Prabhakaran: No, no, no. Kilian's construction doesn't involve the circuit but you could -- yeah, so [inaudible].
>>: Some kind of [inaudible].
>> Manoj Prabhakaran: It's [inaudible] okay.
>>: [inaudible].
>> Manoj Prabhakaran: Yes. And NC0 function you can get a polynomial size unconditional randomized encoding. So Kilian doesn't call it a randomized encoding, but I guess you can look at it that way. We do use that kind of model explicitly. We use, for those of you who are familiar with the terminology what would be called a decomposable randomized encoding. Another way to look at it is that it's a Yao's garbled circuit specialized for NC0 functions without using pseudorandom generators for encryption, right, you would instead use runtime parallelization. The runtime parallelization will grow exponentially with the depth of the circuit but if it's NC0 you're fine. Okay.
And we like to build a NISC/OT for certified OT. That will be like our primitive.
Once we have that, then we can compile any randomized encoding into a full-fledged NISC protocol. You will have unconditional security. So this is kind of a main -- so I'll go over both but this is the main, you know, meaty part there

and will be used using cautious it will be realized using MPC in the head that I'll be talking about.
Does this idea of, you know, taking unconditionally secure -- sorry, not unconditional, taking -- sitting on a secure protocol and compiling it with a certified OT functionality does extend to beyond NC0 also. But then this is not going to be unconditionally secure. You need to use PRG. And then this compilation won't use the PRG in a black box way okay? So if you -- again if you didn't care about black box PRG this should have been a way to get NISC/OT.
For not just NC0, all the way, okay. But since we want to stick to black box PRG we don't use this.
And I should mention -- so both this construction here and the one in IPS, they use -- they both build this certified OT, they both dog the difference in the two constructions is how the certified OT is built. In IPS it's -- it has a, you know, bigger overhead, theta K overhead, kappa overhead. [inaudible] we get a -- we get only a polylog overhead. And the difference is the MPC that's involved in building the MPC in the head. Yeah?
>>: [inaudible].
>> Manoj Prabhakaran: I will.
>>: Okay.
>> Manoj Prabhakaran: So, yeah. Okay.
>>: What is DIK.
>> Manoj Prabhakaran: So the efficiency we get all the polylogs come from this protocol Damgard, Ishai and I don't know the name of K. No, no, no, it's --
>>: [inaudible].
>> Manoj Prabhakaran: No, it's not Kushilevitz, it's a student -- I think it's a student of Damgard's. It was in crypto or Eurocrypt last year. This protocol has the -- so you should think about the communication complexity in protocols and we try to minimize that. This protocol myself the effort, the work, the total computation done, in particular the views of the parties. That will be polylog kappa, the overhead per gate. Okay. So that's where some of our efficiency comes from.
Okay. So I should describe what certified OT is. So in certified OT there is a -- and it's parameterized by a predicate again. Call it P third. That's the certificate predicate. It's fixed from the functionality. The sender inputs a bunch of pairs of strings, okay. So for I equal to 1 to L it will input SI0 and SI1. So these are possibly for doing OT.
In addition it can present a witness to the functionality, W. The receiver wants to pick up -- wants to do OT on these strings. So it has bits choice bits B1 to BL.

What does the receiver get? Well, it will get these bits that it asked for. So SI,
BI, right? It will get those bits. In addition it will get -- you know, the -- you'll evaluate the certificate or the predicate and say whether, you know, W is a -- W proves that S has the property. S is all the inputs that the sender has input.
Okay?
So why would this be useful? You know, this like you are presenting something about the garbled circuit and this predicate can actually check if the garbled circuit is constructed correctly up to some -- I'll say, you know, where exactly -- how exactly we use it. But that's so that certified OT cannot just give you the stuff you picked up, it's a number. You don't see -- as a sender you don't see all of the set S. So you cannot really check, you know, if some property holds important the entire input -- set of inputs, right? So this is the certified OT will do it for you have. It can check if whatever property you are interested in holds for the entire set of inputs. Does that make sense?
>>: So you're thinking of this SIs as like the entire garbled circuit essentially?
>> Manoj Prabhakaran: Yes.
>>: What is W?
>> Manoj Prabhakaran: So you'll use randomness to build this garbled circuit, not just the stuff you send -- I mean, so -- so there will be not so -- this would be the keys in the garbled circuit but you will actually present more things to the certified OT functionality. Okay? In particular certified OT functionality is not going to make any PRG calls. So you have to present the PRG values.
Okay. So how do we realize -- so this is the certified OT functionality, okay?
How do we realize this? We take an MPC -- consider an MPC functionality which is defined on a large number of parties. Okay? So there is one party which we'll call the sender. So this is just something that will be run in the head, right? So it will never be actually implemented. There will be -- so again be more than two parties, lot of parties. There will be one sender. There will be two L receivers. L is the number of OTs you want to do. So we call the receivers RI0 and RI1. And there will be a large number of servers. Okay? The servers do not have inputs or outputs. The sender's input will be exactly what the certified OT will require as input. So in this MPC functionality the sender's input is what the certified OT will require the sender to input. So the sender will be that sender.
The receivers do not have any input. So it's not exactly these receivers. But instead every receiver RIB gets its string. So for each of these strings there is one designated receiver who will receive it, okay? And it also get the certificate.
Okay? So every receiver also gets this predicate, whether the condition is satisfied or not.
Okay. So that's MPC you should imagine.
>>: [inaudible] servers don't get --

>> Manoj Prabhakaran: Servers will demand the MPC protocol for you. Okay.
So this is the functionality in which the servers do not do anything. But in the protocol the servers will do something. Okay? So we'll take a protocol. They'll need a protocol rho for this particular functionality. And we need to be secure against passive corruption of up to T servers. Okay? So the server [inaudible] typically MPC protocol in which the inputs are shared to the servers but will be, you know, sufficiently shared so that you take up to T servers you don't learn anything about the inputs or the outputs.
So -- and you can also corrupt any number of clients. If you corrupt the receiver of course you will learn this bit, right? If you corrupt the sender you will learn all the bits and so forth. So you can corrupt any number of clients, clients meaning the sender or the receiver. As well as up to T servers. And it will be passive secure. This is a passive corruption.
Also we need for the same number of corruptions up to T servers any number of clients. We need this property of robustness, namely, you know, if you corrupt actively maybe you'll learn things you're not supposed to learn but you cannot change the correctness. Uncorrupted parties will get only the correct output, okay?
So we'll require a protocol with this kind of robust passive security. There are several protocols but the one which will meet our security will require will be this
DIK protocol -- sorry, the efficient requirements will be the DIK protocol. Okay?
Okay.
So what exactly -- how exactly is MPC in the head carried out? It's, you know, same idea as in this paper IKOS from a few years back. So [inaudible] are co-authors in this paper: So sender will run this MPC in its head, the whole execution, and prepares views of all the parties. Views consist of the random message uses and all the messages that we'll see, okay, and its inputs if it has inputs. The messages that it sends are defined by this -- messages that it receives on its randomness string. So that's his view.
And there are -- so this is network of, you know, one sender, many servers who talk to each other and a bunch of receivers. The receivers do not talk to each other, they just get cautious they just talk to the servers. You need a protocol of that. And our receiver will -- so Alice will use OT to pick up a few views. What will it pick up? First of all it will pick up one out of every pair of such views, RI0,
RI1, it will pick up RIBI, okay? Thereby it will learn SIBI. Also it will pick up a bunch of server views, okay? So each server view is picked up with probability one over T. Even if Alice malicious view under enforces probability can be done using OTs. And if she detects any inconsistency between views, okay, namely if you are honest -- I picked up two servers and if this server is honest, according to what messages it got it should have sent this message, but this server is reporting that it received random message, that's an inconsistency, okay? So again say this edge is inconsistent. If you see any such inconsistency then you abort.

And the MPC that we will use will be the DIK MPC. That will give us the efficiency we're looking for. Okay. Why is this secure? Okay. Why is this secure? You need to consider two cases of static eruption. Security against
Alice. So the protocol is a private protocol. Alice picks up this T server views but, you know, you can corrupt T servers and you don't learn anything. Right?
And another thing is that she might actually learn, you know, her inputs to these
OTs is exactly her inputs to the certified OT functionality. Her inputs to the OTs in this protocol that I described is her inputs to OTs in the certified OT protocol is inputs to certain OT functionality.
So what does she feel is a valid input. So she cannot cheat by feeding invalid inputs. The only thing she does in this protocol number is pick up a bunch of stuff using OTs. And she'll also pick up bunch of server inputs where she doesn't have control. It's -- you know, it's randomly one over T probability server value comes to her. So she doesn't have any room for cheating, right? The servers that she picks do not reveal any information because there's privacy of the MPC protocol. And there is not other room for cheating. Okay? So --
>>: So you're picking -- you're getting the views of the constant number of servers, right, because there are --
>> Manoj Prabhakaran: Oh, okay. I set probably something wrong. You pick up essentially order T servers. The probability so that you pick up less than T servers but sort T servers. Okay? Okay. Security against corrupt Bob is a more interesting analysis but I think I will skip that because it's essentially the same in
IKOS, and I'm really running short of time. Look at it by saying if there are only a few inconsistencies then, you know, it can be explained by having a few corrupt servers and they cannot change the security. There are many inconsistencies then it will be caught. And now if -- so that's a [inaudible] if there are many
[inaudible] if it's not caught you can argue actually that the -- you know, the abort probability can be simulated just in terms of an input value disjunction, okay?
So I'll skip that. You should believe me that that will give us what we wanted.
Okay? So all of this is just to say we can build this thing, okay, certified OT. And how to go from that to this is you start with -- say a perfectly secure Yao's garbled circuit protocol and Bob needs to prove that the garbled circuit was used in a -- prepared correctly. And for that you use certified OT -- the -- it's fairly straightforward. So let me actually -- do you want me to go over that? So the certified OT will take -- so I said -- so in the -- in this NISC, which is semi-honest secure, like say Yao's garbled circuit, use the OT, right? Instead people will be using the certified OT now. That in addition to that, certified OT -- so certified OT will carry out the job of the original OT. In addition to that, it will take -- it will verify that Bob -- Bob created the garbled circuit correctly. Right? Okay. So --
>>: That certification a function that could be used in certifying OT, the correctness function for --
>> Manoj Prabhakaran: Yes. So maybe one more thing to find out is this is unconditional protocol. So there is no PRG involved in this, right? So it's a simple function saying that everything is formed correctly. And last before Alice

can cheat Bob, when all our inputs are valid, so we do require that this protocol do have that property, that all the inputs are actually -- her inputs to OT are actually her inputs to -- in the functionality. Okay? So Alice doesn't have room to cheat and Bob cannot really cheat because of the certification, but he can cause input disjunction abort as before. He can cause certified OT to abort, right, because we only have this kind of certified OT.
So that will mean this -- these inputs are the same. The inputs of certified OT are the same as the inputs to the NC0 function. So this will be an IVD abort for the
NC0 function also. So that's how we get this. Okay?
>>: So why the certified OT protocol pass up this [inaudible] issue? Where does it come from?
>> Manoj Prabhakaran: Oh --
>>: So this previous [inaudible].
>> Manoj Prabhakaran: Okay. I'll show you in a second. Because I can construct -- I can construct a view. Okay. This bullet is slightly wrong. But it's supposed to be the same as this bullet. I forgot to change it when I did it. Okay.
So this bullet as it says, you know, always picks up RIBI. So if I put in a bad
RIBI, for instance, it's a bad view. You pick up, it will be inconsistent with some server. Right? So you abort only if you pick this up. So I can -- you know, I can
-- if you abort --
>>: The subset and I could say is one of them, you know, bad or not.
>> Manoj Prabhakaran: For instance, yes.
>>: [inaudible].
>> Manoj Prabhakaran: Essentially that's all I can do. That's what the proof will do. Okay. There is an error in the first bullet there, but nobody read it so that's fine. Okay. So that's the first step.
The second interesting step is how to build NISC given some NC0 functionality.
Okay? So I'm kind of out of time. Okay. But we are just starting on the interesting part.
>>: [inaudible].
>> Manoj Prabhakaran: What [inaudible]. Okay. So, yeah, as I said the idea is that this NC0 functions will help you do some sort of -- sorry. Okay. So I'm just describing what kind of NC0 function this will be. Okay. Let me define what
NISC/NC0 is. There will be some function H, in NC0 function and it has to have the property that gives outputs only to Alice. It takes inputs from both parties, gives output only to Alice. And a we'll also require that Alice inputs to this NC0 function should be the same all in all constructions once we reuse it we will

require that this NC0 function takes the same input as for the functionality they are trying to achieve. All right.
Okay. So all these three variants use Yao's garbled circuit and something called oblivious MAC. So let me quickly try to recall what Yao's garbled circuit is. This slight variant from what you might have seen typically. This has also been, you know, described in the literature in this form but it's slightly different. Okay.
So this is kind of the circuit C. Alice wants to learn CX of X, Y. Bob takes the circuit C and for each wire there is a mask bit. Okay? Random bit. And you could now imagine a new gate functionality. When put up prime it means masked, when I don't have the prime it's unmasked, okay? So a new gate functionality of two masked bits, two masked wire values. First you unmask them. You apply the original gate function, and then you mask it. Okay?
So that's this F of G defines a gate functionality. It may be and, or, or something like that. It takes two wires and two bits and outputs one bit. And this F prime is just the -- you know, in the garbled circuit the function, the gate function.
Okay. So you might -- your garbled circuit consists of tables like this. So okay for the gate number one your A prime and b prime could be zero -- if it's zero zero, my C prime the garbled output is say some value zero. I get this by unmasking A prime and B prime, applying the original function and then masking it. Okay?
And I'll do this for every gate. And that's my garbled circuit essentially. There is no garbling in Alice's input wires and also in the output wire. For those wires, W, this mask which I call R of W is zero. Now, I'm not done. But so far seeing only the wire values and the garbled circuit valuation, right. I see the gate inputs and gate outputs for this garbled circuit. I don't get any information other than the output. And Alice's inputs. Okay? So if I take an X and Y and evaluate the circuit, and I don't item what you these masks bits are, all you get information theoretically is Alice inputs and the output.
However, that's not all that I would see. I would typically also see the gate functions. If I get to see the this table also, then we have a problem. And I can look at this and say oh, there's only 1,1 and 3,0 and I know that this is a and gate, then I know that this, you know, C prime is masked with 0, you know, bit 0, right, things like that.
So we need to keep it all encrypted, okay? And so we need to keep this C prime encrypted. But then where are the keys going to sit? They will be sitting encrypted along with A prime and B prime. Okay? So you need the keys also.
So this is what -- so if you have a gate like this and, you know, what you will keep
-- okay. What you will have is for each wire there will be two keys, a zero key and a one key. And what you will keep in the table instead of just that plain C prime, what you will keep is an encryption of C prime and the wire case, you know, the key for the wire, W on the value C or C prime. Doesn't matter. It's not labeled. You don't see if it is -- you know, what is a C inside. You just get a K.
Okay?

And this will be encrypted using the keys for the wires U and V with the values A and B. Okay? One more thing. The description is different for indicates, okay.
And seeing there is also a tag for the encryption. More formally it's easier to think of this encryption as using a PRF, the way you would use encryption you do symmetry key encryption. So the key is, you know, the key for the PRF, the C for the PRF, and you call the PRF on the tag. So when I change a gate, I'm using a totally different set of masks, right? So to encrypt I take the message, I mask it with both these masks. Okay? This is the encryption.
Instead of writing all that, I'll just denote it by this. Okay. So for the gate G and for A prime, B prime, so that specifies a role in that table, I keep this entry as a last element. Okay. An for protocol is that Alice will use her keys to pick up KW,
XW for wires or W for inputs. Okay? So she will pick up if it is zero or one, she will pick up only one of the two values of KW. Bob will send the garbled circuit for this table. And for each of his input wires he will send its key. Okay? But looking at this key, you don't know whether it's a key for zero or key for one.
Then always evaluates by, you know, decrypting, you know, the entire table and she gets -- she gets C prime and the key at each gate. And, you know, gets the output, right? As we said, the trouble is that if Bob is malicious he can make
Alice evaluate any arbitrary function. Or you now know what he puts in those gates. Okay.
So we want some more use NC0 function to check correctness. The catch is that this NC0 function should not include the PRG code, okay, use the PRG code in a black box way. So we can not really check if, you know, this encryption is correct. Right? We don't know what -- we can not use the PRG code and this
NC0 function. Okay. I'll get to that.
And so [inaudible] a simple idea and I call it oblivious MAC. But it's a very simple idea. Just MAC, it's a -- but let me define oblivious MAC. So this is a primitive again in the -- you know, in the NISC kind of setting. Alice and Bob both have inputs only Alice gets output. Alice input is a key for MAC'ing and Bob's input is a message and attack. Okay? And what Alice gets is a receipt of the MAC. And the tag is independent of the key. So Bob can create it. It's just a random string.
The oblivious message is that if the tag is chosen at random Bob does it properly, then just the receipt by its served does not really anything about the message. Okay?
So typically that's not the case, right? I -- through the key I get a MAC on a message, I can check if the message is exactly this message or not. So this randomization here is so that you don't learn anything about the message just from the receipt.
But later, if I send you the message and the tag, you can verify it. Okay? That's a verification. And the unforgeability is that you cannot find two message tag pairs with different messages such that I take the receipt by MAC'ing one of them and I try to verify the other message. And it shouldn't verify. Okay? It should be infeasible for you to find such a forgery, okay? So in receipt is like a commitment

to the message. You get a MAC on it but you really don't know what the message is at this point.
>>: [inaudible].
>> Manoj Prabhakaran: It's a -- well, the reason it's a MAC is because it's really a MAC. You can take a one-time MAC, okay, and you MAC it, MAC the messages in the key and this tag and receipt are just shares of the MAC. The only thing is the tag was chosen before the MAC was created. Okay? So it's a very simple thing. I just defined it kind of laboriously but this is all it is. This is all you can use. So the received is just share of the MAC on the message. But you hold only one share. The other share is with the other guy. But the point is the other share could have been chosen without knowing the MAC, right? Or the key or anything. Okay.
Now, the first construction -- there are three constructions but I'll probably just do this one. It's a very lean construction, gets you predicated abort only though.
But as you define NISC NC0 you define the NC0 functionality. Okay. So it takes from Bob the wire masks. Okay. That's all. It doesn't take anything about the keys, it doesn't take over any input about the PRG or anything. It just takes the wire masks, okay, of the garbled circuit that Bob is preparing. And then it can compute this bit C prime so it can essentially compute this table, the unencrypted original table, right?
And for each row in that table it carries out an oblivious MAC on the C prime.
And it takes in addition to this, it takes a tag from Bob and gives a receipt to
Alice, takes a key from Alice and gives a receipt to Alice. Okay? So each of these entries in each row the C prime entry is MAC'd. And Alice gets a receipt for it. For each row there is a different key that Alice will use. Okay?
In addition it will also carry out the OT's job in garbled circuit, namely she can feed her -- she can feed her inputs to the functionality and pick up the wire keys for her inputs.
Okay. So that's what the NC0 function does. I said it will do MAC'ing, right?
MAC'ing is actually very simple in this, because you are MAC'ing one bit. And information there MAC of a bit is just a half a bit key. I'll give you the first half of the key if the bit is zero, I'll give you the second half of the key if the bit is one, right? And if you don't know the key, you cannot force. So it's a one-time MAC.
So it's a very simple functionality that this thing is carrying out. It's NC0 and it's pretty simple. Okay. So what does Bob do after this -- along with this accessing edge? Bob will in the clear send the garbled circuit to Alice. And he's supposed to send -- I talked about garbled circuit as having encryptions of these form -- this form, but now it will also include the tag for C prime. Okay? This is something that Bob chose, right? Bob doesn't need to talk to the functionality to get this tag.
He chooses random tags.
So this is the encryption that he sends in each -- in each entry of that table. This
[inaudible] enough to ensure correctness, okay? So as a -- so at any -- in any

row, if the garbled circuit and Alice decrypts it, gets some C prime, who knows and Bob might use -- may not have encrypted things correctly, whatever. She gets some C prime and tag. If they are verified for this particular G -- the key for the corresponding row, the key and the receipt, if they verify, then it means that the C prime is correct. Okay? You have negligible probability of making a forgery here.
So that's all that Alice needs to ensure correctness. However, Bob can do -- Bob can cause Alice to abort, right? He can put a wrong C prime or wrong tag for instance. And by causing Alice to abort, he can -- the abort can depend on
Alice's input. Okay? But if this is no abort, then Alice is guaranteed that throughout the evaluation the C prime -- so let me say that once more. What does Alice do at every step when Alice decrypts the garbled circuit, takes this thing out, she has a corresponding little C, then she will verify the C prime -- the tag and C prime, right? So if -- she never aborts and all the while she evaluated
R exactly correct [inaudible] okay? Then the output is correct.
But we get predicated about security because the abort can depend upon the inputs in a fairly complicated way. So I'll maybe skip through the next remaining slides quickly.
To get to the WVD abort instead of the arbitrary predicated abort, we need to do a few modifications. One is that the functionality will now create the garbled circuit, okay? It can not really create the garbled circuit because it cannot access the PRF because we cannot use a non-black boxes on the PRF. So what it will instead do is actually ask Bob to provide it with our PRF query answers. Okay.
And we'll just trust those things.
In addition it won't just MAC this one bit C prime but instead it will MAC these
PRF outcomes, also. Okay?
And that takes care of the availability of Bob to cause arbitrary abort. He can just abort by lying about these PRF values. The circuit, garbled circuit was created by the functionalities. The only thing Bob can do, lie here is creating -- is, you know, giving the wrong PRF values. Okay? To the functionality. That will be detected if that PRF, that particular query is, you know, recovered during the evaluation. And that corresponds to seeing one row in that table was opened, which means a particular value of the -- sorry. Not one row. On these PRF values correspond to values of the wires. So this will correspond as one wire value occurred, okay? And that, you know, so abort happens if one of the -- one of a set of wire values occurs. So it's a wire value disjunction abort.
So let me -- okay. Okay. So I will just show you the animation. It's not -- so we can, you know, get this NISC NC0, plug it in, everything will be, you know -- the errors will appropriate appropriately so if it's an IVD -- so the WVD abort subsumes IVD abort. So this is -- we get [inaudible] WVD abort by this plugging and this NISC NC0 construction. We need to take care of these two. This is done using an input encoding. It's kind of fairly standard, standard with -- in literature is inefficient. So we kind of use the hybrid way, which is like you hybrid in the sense that you use a sharp seed and like a t-wise independent generator

and, you know, that works, works as in its small encoding. And the decoding is quite efficient.
Private circuits I think I don't have time because I have like three slides for that.
You want to ensure some sort of t-wise independent in the wires and the circuit.
You cannot really get that for -- because -- and gate the inputs and the output are correlated, right? Okay. So point is you don't really need for t-wise of independent value wires, we define something called parade t-wise independence. And again achieve it by completing an MPC protocol in the circuit. So this is the same way all the private circuits constructions have been like two papers before this on private circuits.
So same area works and if you use an MPC it's really efficient the total work done should be small because the circuit blows up, according to that. So the point is, you can take a circuit C, combine it into a circuit C prime such that a wire value disjunction abort in C prime tells you nothing about the input. It's independent of the input. So either you can force it to abort with some predetermined probability or you cannot -- you don't make it abort, right? So in the private circuit wire valued disjunction predicate is independent of the input essentially.
Okay. And that's -- whoops. Well, that's whoops. I'm trying to get to the last slide so that you can -- if there are any questions. So that's the summary we get
NISC/OT uses black box which had uses PRG in a black box way. And if you want to work on something, you could think about getting it without using any
PRG at all, showing that it's impossible. Okay. All right. Thanks.
[applause].
>> Manoj Prabhakaran: Any questions? Yeah.
>>: [inaudible].
>> Manoj Prabhakaran: No. I place the -- what you think of as the main ISP protocol is not interactive at all. It takes an outer MPC protocol. The only things we have there are either constant round protocol which uses computational assumptions or, you know, non constant round one which is -- without computational assumptions. That's the MPC outer protocol, okay? And so the
IPS gives you protocols which are not one round, not two rounds, right, it's constant number of rounds. Or if you use computational assumptions [inaudible].
In fact, they don't use black -- PRG in a black box way.
>>: [inaudible] black box.
>> Manoj Prabhakaran: Yeah. Yeah.
>>: So it seems that [inaudible] some kind of randomized input, right, so statistic
-- so when you say it's statistically secure NISC, you're asking for -- since you're asking to an unconditional randomized encoding --

>> Manoj Prabhakaran: Yes. So this is unconditional -- it doesn't have to be --
>>: [inaudible] let's say you [inaudible] okay, [inaudible] adversaries [inaudible] can we get statistically secure [inaudible] in the OT hybrid model?
>> Manoj Prabhakaran: In the OT hybrid model? No, that's an open question.
>>: That is open?
>> Manoj Prabhakaran: Yeah. Yeah. It's can you get Yao --
>>: [inaudible].
>> Manoj Prabhakaran: With only assumptions once I have given OT. Yeah.
That's open. So this is it. This is harder.
>>: Right. It seems -- seems impossible.
>> Manoj Prabhakaran: Yeah. But it will be nice to prove it's impossible. Any other questions? Okay. Thanks for bearing with the long talk.
[applause]