 Okay So thanks to the previous speaker for leaving a few additional minutes for me. So I'm gonna take full advantage of it So I'm Rachel and I'm going to try to tell you about our new work on Bob-Op's construction of Concurrently secure protocols. This is joint work with sort of Rappel at Cornell Okay, so as you have heard many times the problem that we're looking at is this secure multiparty computation problem And in particular the goal here is to allow a set of mutually distrustful players to be able to collectively Collaborately compute any function on their own by just sending a few messages to each other and Two things we want to guarantee is the first correctness that is the output of the computation needs to be delivered correctly and second privacy That's the private inputs of each players should remain hidden and We would like this to hold even when there is no honest majority in the protocol execution So these two intuitive requirements in the literature is formalized by this beautiful concept called Assimilation paradigm where we would like to compare the real world where players simply send a message to each other With an ideal world where they get help from a trustee third party who simply compute the function for them and We would like to say that the real world is actually as correct and the private as the ideal world and Meaning that for every anniversary in the real world launching some attack There will be another anniversary in the ideal world who can launch the same attack So if that's the case then intuitively this must be secure because in an ideal world There's no attack and therefore there will be no attack in the real world either So here's slightly more formulae by saying launching the same attack What we really mean is that it's gonna achieve the same effect on correctness and privacy and in particular for correctness We would like the output of every player in both worlds to be the same and for privacy We would like to see the simulator can learn whatever the real anniversary can learn how by simply simulate its view So in this talk, I'm going to focus on a specific type of anniversary who always performs static malicious corruption So traditionally this multi-party computation Problem is considered in a standalone setting But just as motivated by the previous talk already This is not how the real world look like the real world looks like this So there are many sets of players executing many different protocols or at once and it is possible that now an anniversary can potentially participate in many protocol execution and launch some kind of coordinated attack So what we want is that we want the real world where many Executions of different protocols can simultaneously remain as correct and private as the maximum many Executions in the ideal world with independent trusted third party so as We have heard the name the most desirable and the strongest the formulation of this intuitive requirement is universal Composability it is mostly desirable because they really put forward the strongest Concurrency requirements however because it's so strong and it becomes impossible so in order to get around this impossibility without and In particular without going into additional use of trusted infrastructure Many previous work has started to consider a relaxed notion of security called a super polynomial time simulation where we simply allow the simulator to run a little bit longer and Along the same line there have been a few works Trying to propose related notions as lacks the security notions where they put a precise more precise Condition on how much more powerful those simulator can be But in general overall in all those notions by allowing the simulator to be more powerful The good news is that now concurrent security becomes possible So great however here I would like to argue that these results so far only feasibility results only Why really due to the nature of their non-black box Construction where there's a ton of cop reduction flying around in the protocol So naturally here we would like to seek Black box solutions where then we will have automatically no cop reduction and potentially will give us more efficient protocols So where do we stand with respect to black box? Marder party computation protocol So in the standalone setting great the problem is basically soft After a long line of research so far we have constant round the black box Marder party computation protocol from the minimal assumption of I'm honest OT to the concurrent setting the situation become much less complete and The only positive results we know are those unconditionally secure UC protocols using very strong trustee setup like ideal OT or hardware tokens And in fact, we know no black box construction in any weaker setup model or in the plain model So naturally the question is that can we have it can we get a black box concurrently secure protocol in the plain model and In this work We provide you such a construction So we give a black box construction of concurrent secure Marder party computation protocol in the plain model our protocol is based on the minimal assumption of some honest OT and Achieve security in this model called the UC with super paranormal time helper Without you don't have to know the detail of this model But just keep in mind that it directly implies super paranormal time security and also enjoys universal composition Okay, so great. How do we do that? So the result is achieved in two steps So first of all it follows from the classical results that every functionality can be implemented using ideal OT so this step is Unconditional therefore by definition black box and they achieve security in the UC model So the main body of the work is really try to implement OT using a stand-up Stand-alone some honest OT in a black box way So previous works achieve this step in the standalone setting and in this work We try to tackle the concurrent setting and we implement OT in the UC with super paranormal time helper model So the main tool that we use in this step is a black box construction of a notion called the CC secure commitments Which was first introduced by connecting and passing 2010 and this is really the key notion that Enables our results. So let me first try to tell you what it is So CC secure commitments at a very high level can be viewed as the commitment analog of CC to encryption So look at a man in the middle execution where there's an adversary trying to break the hiding property of a left the commitment While having access to an oracle that breaks commitment of its choice Here by breaking we mean that for every commitment of the world is the diversity sent to the oracle The oracle will return back the committed value in this commitment if it's valid Otherwise it gives bought So I want to note that in fact this formulation is likely different from the original definition in cell p10 There they consider a stronger oracle that gives also the decommission information besides from the committed value The reason that here we're considering this weaker oracle is because in order to get a black box construction We can in fact only achieve this weaker notion But luckily as we show in the paper that this weaker notion also suffices for building concurrently secure protocol Okay, so now with this oracle in mind Where I say that a commitment scheme is Children commitment attack secure or CC secure if in such a man in the middle execution with the committed value oracle One of the two things happen Well, either he forwards the left commitment to the oracle Therefore trivially he gets a committed value. I guarantee no security. This does not happen Then the left-hand side committed value must remain hidden So this is really exactly the same a copy the twin brother of the CC to encryption So in the literature, there is a very closely related notion called the concurrent Nominable commitment some of you may have been wondering what's the relation between them So not many more commitment requires that the diversity should not be able to commit to any related values that's With the commitment that he received So this definition can be equivalently formulated as Allowing the diversity having access to the committed value oracle at the end of the whole Execution and getting all the committed values back in parallel So naturally immediately we have the CCs Commitments is stronger and the implies nominability So now with this definition of CC secure commitment in mind, I can tell you the results in this work More formally into theorems. So the serum one is that said There is a black box construction of CC secure commitment from the minimal assumption of one-way function and The second serum says that once you give me such a commitment and apply some honest OT protocol We can black box they implement the ideal OT functionality in the concurrent setting So for the first serum to give you such a black box construction We actually have to borrow many techniques from previous works in particular like techniques behind the non-black box construction of CC Commitments, we used the black box trapdoor commitment construction in PWO 8 and we used the cut and choose technique for consistency checking originally introduced the four building black box nominable encryptions and A lot of work a lot of a blast went and tears so There's a lot of interesting ideas going on in this step, but because it's so complicated I'm going to spare you This part in this talk and they just focus on the second theorem So what I want to show you is that really CC secure commitment is the key notion The right notion for building black box concurrent secure MPC protocol Feel that even without the first the serum theorem 2 is interesting When it's on because if in practice we're willing to assume that some practical schemes like a yes is Assisted a commitment then plug it into theorem 2 we directly get a very efficient constant round black box concurrent MPC protocol Let's finally try to get our hands dirty a little bit try to prove theorem 2 So first I Just trust me that it falls from previous work that we can in fact start with something stronger Not a some honest OT but Malaysia's Sender OT that is already secure against the Malaysia's Sender But only secure against the some honest receiver and the task here is to try to use Some classical approach so that we can lift up The security against the some honest receiver to security against the Malaysia's receiver So roughly the protocol will look like this where the Sender and the receiver first They do in parallel Many to an Malaysia Sender OT executions using completely random inputs So at this point notice that each of these basic OT execution is only secure against the some honest receiver So what we would like to have is that we want to enforce this actual Malaysia's receiver to behave honestly in those OT executions So in the non-black box word Stribute this is like crypto one-on-one right give us your knowledge to prove that the receiver has acted honestly however, in the black box word we can't do that Instead we're used to cut and choose technique which says ask the Sender to choose half of those OT executions at random and Request the receiver to send back the randomness used in those OT executions and The Sender would only accept if the receiver indeed acted honestly according to those random coins that it reveals in those OT executions So nothing if a receiver can pass such a test with respect to So many OT executions chosen at random and it must be that it has acted honestly in most of the OT executions Otherwise, it would have been caught with high probability So with this very strong guarantee We can then use some known sub protocol called the OT combiner to try to utilize the rest of those The rest of the OT execution that hasn't been opened to transmit the real input Well good This is awesome because it seems like this simple protocol works. We already have a protocol that is secure against the malicious receiver Well, there is only one catch that is the catch is the cut and choose Make the protocol lose its security against the malicious Sender now So without going into too much detail, let me directly tell you where the problem is the problem is Now in order for a security proof Against the malicious Sender to work out the simulator while acting as the receiver need to be able to bias the set That is that it needs to open There's no way of doing it right now with this protocol because here the malicious Sender will simply dictate the set T So naturally to solve it We're gonna change this protocol so that the Sender and the receiver will participate jointly in a coin tossing protocol to decide that the set to be cut and Now with the coin tossing the simulator can bias the set to be cut and the security proof will go through I have just shown you is that a very very at a very high level roughly speaking Give you give me a semi honest OT protocol and the coin tossing protocol We can implement ideal OT in the standalone setting and this is indeed what previous work has shown so now when we move to the concurrent setting the main issue is that I Need a much stronger coin tossing protocol. I need a coin tossing protocol. That's in fact the simulation sound What it means is that no diversity can bias the coin tossing without even if the simulator is doing so Or more formally to see the problem Consider this main middle execution where the diversity is participating in many left and many right-hand side the coin tossing Executions now here the simulator comes along and it wants to bias the coin tossing results for each of the right execution The first execution is as 42 Second execution is as 42 again Well, it can do that So the requirements now is that even when the diversity is Receiving those bias the toy coin tossing executions We would like to say that he himself cannot bias the coin toss results on the left-hand side So our results shows that as long as we have such a simulation son the coin tossing protocol and Plus as I'm honest OT then we can implement ideal OT in the concurrent setting in a very similar way as I have just told you So now everything or the task you have reduced down to constructing such a simulation sound Coin tossing protocol. How do we do that? We're gonna use the CC secure commitment So I'm gonna I guarantee you this construction is really simple. Everyone is gonna get it Okay, so how do I construct such a coin tossing protocol? Take the vanilla coin tossing protocol Everybody knows and simply replace the first commitment with a CC secure commitments So why is this simulation son? Look at this main middle execution? How can a simulator bias the coin tossing result on the right-hand side? It can do so if it can break the CC secure commitments in the first message So now it follows you from the CC security that even if the simulator Has access to a committed value oracle in order to bias the coin tossing results the left-hand side the CC secure commitment is still hiding and Therefore the adversary cannot bias the coin tossing results on the left-hand side done and This concluded the proof for theorem 2 So in summary what I have shown you in this talk is that we give a bubble construction of concomitant secure multi-body computation protocol in the play model and The key construction is a black box CC secure commitment Which I actually didn't tell you about how it is constructed But just I want to really highlight the point that I think CC secure CC security is the key notion and the reading being that in a black box Construction there's lots of cut and choose lots of opening and we would like to guarantee that some security will hold Even with respect to openings So one catch unsatisfactory part of our result is that the construction has a very High round complexity. In fact, it's it's an order and runs. So one obvious question is can we get a better rounds? So that's all what I want to tell you. Thank you