 Good afternoon, everybody. Thanks for rating out all the names for me. I'm here today to talk about two papers here. So first of all, thanks for the authors of the first paper here for letting me present today. But without much ado, let me just get started. This talk is going to be about concurrent secured computation. So let's just briefly recall once again what secured computation is. There's two parties, Alice and Bob, let's say, who have x and y, and they would like to compute f of x and y through a protocol. And the goal of security here is that if you cut up any one party, he learns nothing more than the output of the protocol. This is a very well-studied notion from 1982. And the security guarantees that we began studying were guarantees when we said, well, there's only one thing in this world. We run this protocol pi, and we ask, is this protocol secure? On the other hand, today, things are very different. There is so many different things happening. Right now, while I'm giving this talk, I'm doing a lot of other things. And then we would like to have security for everything put together. So for instance, an adversary who corrupts some subset of parties that we are interacting with as a single person and running a bunch of protocols with could run very many correlated attacks on a bunch of these protocols. And we'd like to guarantee security even in this concurrent setting. This naturally asks the following question that has been well-studied as well, which is, can we design protocols that remain secure even when executed in this concurrent setting of today? The sad news that we had from long time ago is that actually happy sad news, which is that this area is interesting to study because things that we know about standalone secure protocols does not imply security for concurrent security. Well, so then what do we know about this concurrent security? What are some good things about it? Well, if you make global trust assumptions, like the common random string, then we know that general positive results are known for concurrent security. For a very large, in fact, for some of the strongest notions of security, like the UC security. Alternatively, one can relax the security definition to talk about a concept called bounded concurrency, or super polynomial time simulation, in which case we know that, again, there are positive results for a bunch of functionalities. On the other hand, in the very simple plain model, we do not know a generic positive result. And this is quite intriguing, because on the contrary, for standalone computation, we do know positive results in the plain model. So maybe what about negative results? Broad impossibility results are actually known in the plain model, but for very strong notions of concurrency, again, like UC. However, this still leaves some important grabs in our understanding of what concurrency is. Do we really need to have only two levels of concurrency, the one that is standalone or one that is UC? Maybe there's something in between, and what about our understanding of those? This motivated the authors from the first paper to consider the following setting of concurrency. Think about a scenario where there's a bunch of clients and a server. And this is not as complicated as the real world. They're all just running the same protocol with the server. Every single client is running the same protocol by. And the model is even simpler in that we would like to think of either only the clients getting corrupted or the servers getting corrupted. So there is no cross-corruptions. Even in this simple model, but very realistic model, we would like to ask, what are positive results? What are negative results for this setup? It turns out that in this model, there's no positive results for concurrent zero knowledge, which is again very well studied from 1999. And we have impossibility results for some other functionalities. However, a very simple functionality, like the Oblivious Transfer functionality, was something that we did not know whether it was possible or not. And this was left open as late as 2008, very explicitly. And the authors considered this as their motivation to study the notion of fixed roles in concurrency. Now the set of authors, Gargostrovsky, Wisconsin, and myself, we considered the following different problem, which is, well, suppose there is a bunch of clients and servers once again communicating with each other. They would like to run the same protocol many times. However, the inputs for all of these protocols are decided a priori before the protocols even began. It's not like you run a protocol, then you take something from it and then make up inputs again. In this fixed input setting, we asked, what is possible and what is not possible? In this setting, it was known that impossibility results existed for some very specific functionalities. And so the national question to ask was, what about the rest of the functionalities? These two seemingly different motivations led all of us together to come up with the following core result, which I'll be presenting today, which is that concurrent self-composition is actually impossible for the oblivious transfer functionality, not just in either of these settings, but in both these settings, actually, in both fixed input and fixed role settings. And both papers sort of presented this result. This will be the proof that I'll be presenting today. But before we get there, I'd just like to say independent extensions of each of the works. The first work, they presented that concurrent composition is impossible for all non-trivial and symmetric and asymmetric functionalities. They also stated that another notion of computation, which is called stateless computation, was impossible. Agarwal, Goyal, Jain, Prabhakaran, and Sahai. They show a very interesting non-interactive completeness theorem. There's completeness theorems known for standalone computation from 2000 by Kilian. It's a very celebrated result. They showed that this result, which used interaction, actually could be improved. And you could have a non-interactive version of this. And they used this new result that they obtained to show us a corollary that actually concurrent composition was impossible in the fixed-input setting for all non-trivial asymmetric functionalities. So putting these extensions apart for now, I'm going to go back to the case of oblivious transfer, which is a special case. It's going to be impossible. And we're going to study why this is the case, so that we can see some of the technical content of both of our papers. So just to recall, oblivious transfer to gaze. The functionality on the left here, the ideal world, is basically where Alice has two strings, S0 and S1. And Bob has a bit B. And they both communicate to the ideal functionality. And Bob receives SB. This in particular means that Bob has no idea about S1 minus B. And Alice has no idea about the bit B itself. So in this real world, there's no ideal guy. And so Alice and Bob are running a protocol pi. And we would like to have this level of security, which is that these two executions are indistinguishable. And not only for the standalone setting, but when it's run multiple times. When the same protocol is run multiple times. What I'm going to do is I'm going to start with an attack on this protocol. When this protocol is run concurrently with some other protocol in the environment. So let's just study this attack, which is known in theory as the chosen protocol attack. So here we have Alice and Bob. Bob is going to be our bad guy today. What Bob is going to do is he's going to run a similar to the OT protocol with Dave. This is called the chosen protocol. I'm going to change the protocol from pi OT in a bit. And all that he's going to do is he's going to just forward all the messages that Alice sends to him, to Dave, and forward all the messages that Dave sends to him, to Alice. If they were both running pi OT, Alice and Bob would not realize that anything was going wrong, because it would just seem like they're just talking to each other. In this setting, we're going to change the protocol on the right a little bit. And we're going to say that Dave, once the protocol is complete, is going to do the following change. He's going to check if the output that he received from this protocol is actually, we already are going to give him S0 and S1, is actually equal to SP. So he's going to check if this condition is true. If this condition is true, he's going to send S1 minus B. So from this, we see that this protocol, this new protocol that we created out of the pi OT protocol renders the protocol insecure in some way, hopefully, because Bob learns S1 minus B if run concurrently. Now let's look at what happens in the ideal world. In an ideal scenario where Bob actually talks to some ideal guy, he does not have this advantage of messages that Alice sent him. So he could not just replay these messages to Dave. Instead, now Bob is supposed to somehow cook up these messages from these interactions that he has with the ideal world guy. From these interactions, he could learn one of S0 or S1, but he can never learn both. And in this protocol, Bob could play with some B, which he does not know about. So Dave could play with some B, which Bob does not know about. And therefore, he will succeed in this protocol with probability at most half. This means that he learns S1 minus B, which is some information that he did not have with probability at most half. So this shows that the real scenario, which happened here, and the ideal scenario, which is happening here, is sort of distinguishable with probability half. So therefore, the protocol pi ot that we replaced by the ideal version of it is no longer secure if it's run concurrently with this chosen protocol here. This already shows that composing these two protocols is a bad idea. Now what we would like to do, ideally, is to go from here to a scenario where we go to what I consider some of the weakest models of concurrency, where we have fixed roles, fixed input, and the same protocol being run again and again. That is the next step, which is we have additional parties here. We introduce a new party, Dave. So we would like to get rid of him. We get rid of him by using a technique that's well known, known as garbled circuits. Garbled circuits basically help us replace any functionality, including a reactive functionality like Dave, who is actually reacting to a protocol by just a box or some cryptographic mechanism, which you can interact to one time. So what we're going to do is we're going to give Bob the garbled circuit. We're going to give Alice the keys for the garbled circuit. And Bob is going to interact with this garbled circuit instead of Dave. So there's just one OT protocol that's running right now. And this is all happening inside Bob's head. And what Bob is actually going to do is he's going to go ahead, and in order to obtain these keys for the garbled circuit, he's going to start many more OT sessions in between some of the messages of these sessions and execute the garbled circuit and be able to replay the attack that we saw earlier. So in this setting now, when we make this transformation, we have that Alice and Bob are basically running a lot of OT protocols. Bob is the only party who is corrupted. Therefore, this is in the setting of fixed roles. It also turns out that the inputs for the party Alice could be set up priori before any of the computation begins. And therefore, that would make it in the fixed input setting. And that would be our main impossibility result. Since I have some more minutes, I think I'm going to start with the complete proof now, because that was just a primer. Actually, I was just kidding. You should just go see the full version. Because unlike most papers, which have zero full versions online, some papers, which are one full version online, our papers, because I'm presenting two papers today, actually has two full versions available. So thank you. And many thanks also to Abhishek Jain and Shweta Agarwal, who helped me make these slides. So thanks. Thank you.