 Thank you very much. I don't think you're hearing me. Do you? Okay, perfect. So Thanks for introduction. I'm going to talk about And non-interactive commitments and tell you why we found them curious together with Rafa at Cornell and Either way the full version of the paper is available on my home page now. Hopefully it's going to appear in a print also pretty soon depending on different factors So a few words about modern cryptography and One-way functions so from fifties after the work of Shannon, we know that Many interesting things in cryptography are not possible to be done in an information theoretically secure way So we are used to computational assumptions now In modern cryptography and in particular one-way function has been a very central player player in this in this framework So if you assume that some function is easily computable, but hard to invert You can do many things with it but This is not a very generous assumption In fact almost everything that we want to do in cryptography needs one way in a some way around the game and Just by assuming that one-way function exists We can do lots of things like encryption Signatures and so on so it has been very influential or very useful assumption But this is not the only assumption that we have in crypto We also have a stronger assumptions to do things that we cannot do with one-way function One other assumption that I want to compare it with one-way function somehow is one-way permutation very close to one-way function It's a one-way function which in addition to being one way. It's also a permutation that's the definition and There is a story about these two primitives I call it a successor story So the story is that over and over over the history of crypto We started by doing something based on the assumption that one-way permutation exists and by the time by hard work We relax this assumption We just use that it's one-to-one one-way function and then regular one-way function eventually we could do it just by assuming that there is one-way function somewhere and The examples are numerous in this Story like pseudo random generator is one statistical zero knowledge or signatures But what makes this a story probably even more interesting is that? We know from early 80s that there is no direct way to go from one-way function to one-way permutation So these two primitives are qualitatively different In a in a good way that you can formalize it in a black box way. They're different. They're separated However, anything that we wanted to really do and we did it based on one-way permutation We ended up just think it based on one-way function at least for many cases so One question that we have in mind in this talk in this work is is it something that is going to happen all the time? Or there are some outliers to this phenomenon Can we always substitute one-way permutation with one-way functions in? Real applications that we care about or no sometimes perhaps not or you can ask this question in a different way Is there some natural cryptographic task that you can do it based on one-way permutation? but not based on one-way function and When I say you cannot do it based on one-way function I have to be clear what I mean here now because you should anticipate to prove it logically speaking Otherwise we have to prove that one-way function exists this primitive doesn't what we do is to restrict ourselves to a framework, which is general enough and Interesting so that when you prove impossibility in that framework is still meaningful and that is going to be the black box construction and separation framework What is this framework? Well If you will think of some cryptographic Construction right now in your mind most probably it's going to be a black box one because most of our techniques in crypto are actually black box techniques in our constructions What what do we mean by black box? You want to do some task and you use some primitive support It's one-way function permutation. You really don't look at the code of this primitive you only use the input-out behavior and As opposed to this black box where you can think of a non-black box way that you really look inside the code of the Primitive you really get the gates and you also rely on the fact that it's efficiently implemented So when it's something but in black box, you don't care about efficiency It could be highly inefficient and you can still use it as an oracle so many things are in fact black box and The good thing is that they're usually more efficient That's one other reason that we care about them and there are more modular way of designing protocols that they can Incorporate things that are not really Turing machines like human brain. For example, you can have them a part of your system design Well, now that I mentioned this black box versus not black box I want to also mention another another success story that is relevant to us This story is the following that again for many cases in crypto we started with a non-black box construction of Some primitive based on some other primitive and by the time We could manage to get rid of this non-black box feature and make it really the way that we wanted to look like we made them black box and examples for this are from secure computation and also variants of commitment and I also want to clarify that this success story is not referring to Security reductions, so in this talk whenever I say black box non-black box always I'm talking about the implementation of your Protocol and we know actually cases where non-black box proofs of security are Provably stronger than black box proof of security So this is not an area that I'm going to get into I'm going to just stick to implementation reductions So this is the second question perhaps a little deeper than the first one is it possible to always get rid of non-black box use of primitives and make them black box construction or Is there a case that a non-black box use of a primitive primitive is in fact inherently useful? provably or useful So these are the two questions that we study in this work and our results Are about Answering these two questions using a primitive that you saw in the title Basically, it's going to be non-attractive commitments the primitive that plays the central role in this work I'm going to show it with and I see from someone so just keep in mind this acronym So the first result that we show is that It is known that one me permutation can be used to obtain non-attractive commitments But we show that you cannot use general one-way functions to get non-attractive commitments So somehow for this application these two primitives basically start to behave differently The second result is that if you want to get non-attractive commitments There is some cryptographic assumption that you can use it to obtain non-attractive commitments But you have to really use it in non-black box way in a provably Formal way, so you there is a non-black box way to it. You cannot be in a black box way So let's just briefly Remember what commitments are one non-attractive commitments are so a commitment scheme is just a digital version of a secure vault You want a protocol that simulates this game that I'm going to just show you the game is that you have a sender It has a secret bit B and wants to send it to the receiver, but not just Not just the bit B It puts it inside a box and locks the box and sends it over and we call this commitment phase in the second phase We should call it the commitment The sender is going to reveal the password of the box and the receiver can open it So this this picture this process has a bunch of properties It's hiding in the sense that the receiver doesn't know the speed before getting the password It's binding in the sense that after sending the box. You cannot really change your mind about what you put inside it The way that I pictured it here. It's non-attractive. So there is not much interaction going on There's only one message from sender to receiver in both phases And you can think of many applications. It's quite basic primitive So like zero knowledge coin tossing many other things and if you really Care about certain applications you can use the fact that it's even non-attractive and from again early 80s we know that What me permutation is sufficient as an assumption to get this primitive Based on yours X or Emma and Hardcore bit of Blam and Mikali So this is the primitive that we care and it's going to play a role in the rest of the talk I'm gonna first show you a very high level of ideas of the black box separation that we get and then I'm going to show You some assumption that is useful to get non-attractive commitments But only in a inherently non-black box way and depending on the time some open questions toward the end Okay, so first black box separation from moment function Well, there is a general technique to separate things from moment function And this general technique goes back to the first paper that is started this field by impoglioz and rudish the idea is pretty simple but Pretty cute at the same time. It says if you want to rule out black box constructions from one way function Well, because the construction that you're assuming it exists and you want to refute it. It's black box It doesn't care whether your function won't be function is efficient or not in particular You can use a random function instead of a efficient function in your construction And it is still has to work as an implementation of your primitive in this case It's an unattractive commitment So if you use a random oracle and if you can break your scheme with respect to this random oracle by asking Go leave polynomial equities to this random oracle then the conclusion is that you have obtained a black box separation You have ruled out the possibility of this black box construction Why is it working this way? The point is that if you really break your scheme in the random oracle model the security of your scheme, which is part of your the design of your Primitive would translate your attack into an attack against a random oracle It would tell you how to invert a random oracle by only polynomial and equities and that is easy to show that it's impossible because random oracle is Information theoretically one way. So that is the reason that if you could do this you get a separation Very simple framework. Can we use this framework in our setting? Well, we want to do this We want to look at an implementation of non-attractive commitment in the random oracle model We want to break it with few queries to the oracle The problem is that we cannot do this The reason is that relative to a random oracle one to one moment function exists You can show that not so hard and if you have one to one moment function, you can still get non-attractive commitment So we cannot really hope to use this framework the way I depicted it But what we are going to do we are going to modify this framework a little bit and this time it's going to work for us We are not using a completely random oracle in our proof We are going to use something which we call partially fixed random oracle It is close to a random oracle in the sense that it is fixed somehow over polynomial in many points And it's completely random on any other point So you can see that if you look at this type of oracles they could be highly Far from being one to one this fixed part. You don't have full control over how they're fixed What you only know about this oracle is that it's random out of that out of that area So the high-level structure of the proof is like this We want to break non-attractive commitments with respect to this type of oracle We cannot hope to break the hiding and biting both Because you can always get either of them information theoretically at the cost of sacrificing the other one So what we can show is that you can break either of them? Namely we show that in the random oracle model either the receiver can guess What is inside the box by asking only polynomial queries actually with respect to random oracle Or if this attack that I'm going to describe quickly fails we show how a receiver can sorry now a sender can cheat by Sending a commitment and later opening into both zero and one So this the first attack is very simple. It just says you are the receiver you get a commitment You don't know what has happened on the sender side try to guess which queries the sender has asked from the random oracle and Ask those queries also and after a while try to guess the content just by outputting the more likely value What we show that if this simple attack fails then the sender can cheat with respect to some partially fixed random oracle So because of the time I'm not gonna get into details I'm just gonna show you how the oracle looks like from a very far perspective So this oracle that the the sender is going to use this is the domain This is the range. It's almost random everywhere. The dollar means random But it is fixed over some parts of the domain So the middle circle is a part that I fix it based on the attack that the receiver tried to do and it failed so based on that attack I'm going to come up with some partial function and I'm gonna fix it here and Because this fixed part does not reveal the bit B You can show it's easy to see that because it doesn't tell you the bit B You can always extend this oracle in a way that it is consistent with some commitment to zero Otherwise you would know it's one and the same argument tells you that you can always extend this oracle in a way That is consistent with some commitment to one So the hard thing is to show that you can actually come up with single oracle that is consistent with both of them at the same time This is the non-trivial part and we show that this is actually possible using probabilistic method Now what you get is that you get some oracle that is actually partially fixed random So it is a strongly one way and with respect to this oracle the sender You can become into both zero and one after sending the commitment, which is a cheating strategy So therefore you get a contradiction and you get the black box separation Okay So now we prove this theorem no black box construction of non-attackive commitment from one way function this answers our first general question Now I'm going to show you some assumption that you can use to get non-attackive commitment, but only in a non-black box way First just recall what we proved so far no black box construction of non-attackive commitment from one way function The funny thing is the couple of years ago Barak on Ganbatan showed that actually you can use one way function to get non-attackive commitment So what's going on they proved the opposite of our result what they showed is that if you believe certain secret lower bounds You can use those lower bonds to get de-randomization Tools and using those de-randomization tools you can de-randomize now or two message protocol Which is based on one way function and you get a completely non-attackive commitment scheme So the key point is not this assumption the key point is that this construction actually number box it really uses the code of the Implementation of the scheme to de-randomize it in particular uses the code of the one way function as well So these two are not contradictory in fact you can put them together and under the same secret secret lower bound assumption The conclusion is that you can obtain non-attractive commitments from bombing function only in a non-black box way So this is a conditional answer to our second question. I don't like this conditional answer So we make it unconditional we Go one a step further We show that if you go over our proof, which I'm not going to do quite Like that we see that there is a separation in a stronger form We can separate non-attractive commitments not just from one way function but even if you assume that one way function has some pseudo random properties that we call it heating one way function and The nice thing about heating one way function is that now you can use the heating one way function also in the construction of bov and It is a still non-black box However, you do not need the secret lower bound assumption anymore because this heating property is basically what you need to de-randomize So now we have a primitive There is no way to use it in a black box way to get non-attractive commitment However, you can use it in a non-black box way to do so therefore putting this together We get some assumption that you can use it to get non-attractive commitment But only in a non-black box way as far as we know This is the first pair of primitives that has this behavior so far. We didn't have any pair of examples like that But I didn't tell you what heating properties I'm not really going to do it Completely but in case really curious what the heating property is you can read this I'm not even gonna read it completely But a function f we call it heating if you can get heating set generators by Enumerating f over a small fixed set like one two three up and in a squared You can get heating set generator. What is heating set generator? Well, it's a set that is going to intersect with many other sets From some family that family has to do with efficient circuits that recognize most of their inputs well, it's a messy condition, but Why we didn't find it so so bad the point is that random oracle actually does have this property So it's a property that is not that far from Conjection like for example a is does have this property. That's why we call it pseudo random basically and The problem is that we didn't use random oracle in our separation. We use something else. Well, we use this Oracle which was partially fixed So is this oracle also heating? Well, this is not that easy to show in fact This is the technical part of the paper that I refer you to the paper to see that We need to really argue about the way that this fixed part is fixed And we have to argue that this is not going to make a problem for this set that we are gonna use for For the heating set generation Okay, so Now I'm just going to briefly tell you One or two open questions before that so one reason to study non-intractive commitments Is that they're useful another example of being useful is to get three message honest very far is your knowledge of schemes So think of like GMW or blombs a scheme if you use a non-intractive commitment there You get some some protocol, which is not negligible error, but it has like weak error soundness Can we do the same by one way function rather than one way permutation? So if you could prove any possibility for this application, it would be a stronger because Non-intractive commitment can be used for this Well, we do not get a full separation here But we show that if you can do this in certain way Something surprising happens you get program checkers for the class NP This is kind of a new type of assumption that very recently is being used used to explain some barriers that we have in Cryptography we cannot do something. Well, we don't prove it's impossible We just tell you that if you want to do it you have to go back and solve a question Which has been over open for 20 years We don't know whether NP is checkable or not, but it seems to be pretty hard to do and For doing this we have to start from our black box construction and turn it into a proof system for co-MP Where the prover has low complexity. That's basically the big picture of what's going on here Which we actually do and the first thing is that this this result is not Generally we assume something about the protocol this assumption still includes something like GMW or blumps protocol as a special case so the first open question is to Really get rid of this extra condition that you didn't describe and get program checker for any three message on a spherifier zero knowledge and perhaps more interestingly Are there more pair of critical primitives that? This phenomena happens namely you can get a reduction there But really the reduction cannot be black box. So this is the first. This is the first pair that we Present in this work the non-black box aspect really comes from the de-randomization Part not from something like cook living so there might be more interesting cases in particular We define the new primitive to answer this question It would be more interesting to look at the primitives that are defined before our work Probably that is the right way to call something natural as a primitive Okay, that's it and thank you very much