 Hi everyone, I'm Rajit and I'm excited to discuss with you about our work Blackbox Non-Interactive Non-Malable Commitments. This is joint work with Takshita Khurana, George Lu and Brent Waters. So let's begin with a motivating example of auctions. Let's say we have three parties and each of them want to bid for some art piece at an auction. Very naturally, the party who bids the maximum amount should get the artwork. But let's imagine that we have to do this over an insecure channel, let's say the Internet. And we have to do this for transparency or convenience reason. A very natural idea to do this is to encrypt our bids and encryption hides our plain text. So intuitively it tells us that this should be a secure protocol. But this intuition turns out to be incorrect. In general, the fact that we've encrypted our bids does not guarantee a new adversary, let's say Mallory from coming in and outputting an encryption which is related to the encryption of one of these parties. So in this particular example, Mallory can come in and output one more than any of these given parties. So let's say it outputs one more than the middle party, then it's outputting an encryption of $101. And in our encryption security game encryption notion, we don't define or prevent such attacks. So in general, we want to prevent such attacks. And what we want is that each of these parties interaction to be independent among one another. So let's say party one's interaction with the auctioneer and party one's interaction with party two, any of these interactions to be independent. And in 1991, we started a rigorous study of what it means to guarantee such independence and prevent such man in the middle attacks. And this area is called non-malable cryptography. For the purpose of this talk, we're only going to focus on a subset of this area called non-malable commitments. So let me describe to you what a commitment is. A commitment is a two-party protocol between, let's say Alice and Bob, where Alice has a message M that she wishes to send or commit to to Bob. So this happens in two phases, a commit phase, where Alice sends the sealed envelope to Bob in an interactive protocol. So let's say commit as a protocol, and that takes in security parameter, message and randomness, and it outputs a commit string C. At the end of this protocol, Bob has this commit string. Another phase is the opening phase. In this, Alice opens the message that she originally committed to to Bob. So at the end of this protocol, Bob has the message that Alice committed to. The open protocol takes in C as the commit string and D as the decommitment string, and outputs a message or bot where bot indicates an unsuccessful opening. So what are the properties that we need? We need hiding. We need that the commit phase hides the message that Alice committed to. So this can be described formally in terms of a security game where we say that the commitment on M0 is computationally indistinguishable from commitment on M1. The other property we need on the opening phase is called binding, where we say that Alice should not be able to output a message different from what she committed to in the commit phase. More formally, we can describe it in terms of a perfect binding notion where we say that let's say C is a commitment to M0, then C cannot be a commitment to M1, where M0 is not equal to M1. So we don't want this equality to hold. So let me describe the commitment model we are in for this particular work. In this particular work, we focus in the non-interactive setting. And what I mean by non-interactive is that the commit and open protocols that I described in the previous slides are actually algorithms. So they output the commit string and the message respectively. And additionally, the model that we'll follow is the tag model of computation. The tag model of computation is that these commit and open algorithms take an extra tag. And imagine that these tags are public values that any of the parties can choose independently and post them publicly. So these two models are actually equivalent, the tag model and the untagged model, if you assume that there are exponentially many tags and that there is a signature scheme. So basically when Alice wants to commit to Bob, she's going to use her tag. And the way the signature scheme works is that the tag is actually a verification key and Alice uses her secret signature key and outputs or signs the original commitment and outputs this tag as the verification key. So I've described to you what the hiding and binding properties are. And this tag model helps us to define something which we call CCA model of non-malability. And this was defined in prior work. And the way I'm going to define this model is I'm going to define an additional algorithm called a VAL algorithm. And this VAL algorithm will only appear in the security proof or in the security definition. And this is an inefficient algorithm that takes in a tag and a commitment com and it outputs a message M which is related to this commitment. So how does the security definition look like? Let's say we have two parties, a challenger and an anniversary. And an anniversary sends a challenge tag to the challenger. And additionally, it gets access to this VAL oracle where it can ask for queries on some tag and some commitment. The challenger can reply back if the tag that it asked for is different from the challenge tag. And it outputs with a message which is related to the commitment. If there was no message related to this commitment, it's going to output Bob. So recall that this VAL can be an inefficient algorithm. And in general, it runs in more time than what you're allowing the adversary to run. So the adversary makes use of this VAL oracle in some non-trivial manner. The adversary then outputs two messages, M0 and M1, and the challenger samples a bit and commits on the challenge tag tag star M of P and sends it to the adversary. The adversary again gets access to some VAL oracle. And at the end of this, it tries to guess whether the message is M0 or the message is M1. So for those of you who are aware of the traditional notions of non-malability, this notion in the non-interactive setting has been shown equivalent to non-malability with respect to commitment. And those of you who are not aware of the way we define non-malability literature, just know that this is the strongest model that people consider when they talk about non-malability. So let's see some of the prior work. So we started in 1991 with the logarithmic ground protocol from one-way functions for non-malable commitments. And since then, we've improved the round complexity and the assumptions that we get these from. So we have three round protocols, two round protocols, and non-interactive protocols. And for this talk, we're going to focus on non-interactive protocols. So how do we build these schemes in literature? We build them through a two-step mechanism, where we first build a non-interactive non-malability commitment scheme for C log, log, lambda, many tags. And then we define a tag amplification procedure. And we output a scheme which can service two to the power of lambda, exponentially many tags. And the purpose of this talk is precisely this tag amplification procedure. So I'm going to describe briefly how some of these non-interactive works do tag amplification. A common feature of all of these works is that the assumption that they use for doing tag amplification is the sub-exponential non-interactive witness indistinguishability. If you're not aware of what a NIVI is, you don't need to worry. But what I want to make a point is that the use of NIVIs makes underlying non-blackbox use of cryptography. And the assumptions that we know NIVIs from are piling your maps, or let's say some de-randomization and trap-dopermutation assumptions. And in cryptography, we generally want to expand the basket of assumptions that we have things from. So ideally, what we would want is we would want a blackbox use of cryptographic protocols. And let's say some more ingredients from which we can do this tag amplification procedure. And this is precisely our result. We get non-interactive, non-malleable commitments, a tag amplification procedure, which amplifies from C log log lambda many tags and is secured against non-uniform adversaries, something which can service two to the power lambda tags and is secured against uniform adversaries. So notice that there's a caveat here that we go from non-uniform adversaries to uniform adversaries. But I'm going to talk a little bit towards the end of the talk of why this caveat exists and how we deal with it. And the positive things that we get is we get blackbox use of cryptography and we eliminate the use of NIVIs. So since we eliminate the use of NIVIs, we use some other ingredients. And these ingredients are hinting PRGs. These were introduced by Coppola and Waters in 2019. And basically they are special kind of PRGs. PRGs is a length expanding function where if you sample the seed randomly, the output of this function is computationally indistinguishable from random. And the hinting PRGs have a special hinting property which I'll explain towards the end of the talk. And I want to say that you know how to construct hinting PRGs from computational interface helmet and learning with errors. So these are new assumptions that now you know tag amplification from. And the second ingredient that we use is keyless collision resistant hash function. A keyless collision resistant hash function has a collision resistant property where we say that you cannot find two inputs with hash to the same value. And the second property that we have is that there is no set up to these collision resistant hash function. So an example of such a collision resistant hash function would be SHA256. And this having no set ups makes it easier for us to have a non-interactive protocol. So let's see how tag amplification occurs in literature or at least in DDN 1991. So we tag amplifier from 2n to 2 to the power n tags. And to get from log log lambda to 2 to the power lambda many tags, you do this tag amplification procedure a few times. So let's focus on getting from 2n to 2 to the power n. So let's say we have a big tag in 2 to the power n space. So tag 1 indicates the first bit and tag n indicates the last bit. I'm going to define small tag, which is going to take the position and the bit. So basically I range this from 1 to n and tag i is a bit, which is 0 or 1. So small tag i is going to range between the space of small tag i is into n. And how are we going to use this encoding? Recall that we have a big tag and a small tag and capital in many of these small tags and each of these small tags are into n. We're going to commit to this using the base commitment scheme on all of these small tags on on the same message. And additionally we're going to attach an ISIC proof saying that all of these commitments are on the same message. So this is a complete tag amplification construction. And to see how the proof works, I have to define the val oracle for you. So the val oracle will proceed in two steps. First it's going to verify that the ISIC proof holds and then it's going to pick up a commitment and open that commitment using the base val oracle. And using this base val oracle, whatever the base val oracle outputs, our bigger val oracle will output that. And the reason we encoded in this particular way is let's say tag j is some query that we make to the val oracle. And tag star is a challenge tag that we define at the start of the CCA hiding game. So recall that the query that you make to the val oracle are different from the challenge tag, tag star. And if they're different, then they're going to differ at some position and some bit value, which means that there's going to be some small tag value, which is going to be completely different from this challenge tag value. So for every j, every query that we make, there's going to exist an i such that there's a small tag which is different from the challenge tag. And the reason we're going to use this is in the proof. So recall that the val oracle proceeded in two steps. It verified the ISIC proof. And open the commitment to one of these N commitments. And now instead of opening to one any of these random commitments, or let's say the first commitment, we're going to open with respect to the ith commitment. And here we crucially rely on the fact that there exists an i, which is different. And the reason you want to do this is you want to rely on commitments which are different from whatever you use the small val oracle here. You want to rely on a small val oracle, which is different from all the challenge tags. And this is precisely which is guaranteed here. So once you rely on a val oracle, which is different from the challenge tags, you're going to simulate the NISIC proof. And after simulating the NISIC proof, you're going to change each of these messages one by one from M to zero. After you've changed all the messages, there is no information about the message remaining. And the probability that the adversary wins the security game cannot be more than half. So notice that this proof technique does not work because it's not in the non-interactive setting. So NISICs require a setup like a common random string. And if you are in our non-malability, non-interactive setting, we cannot have a setup beforehand. And we want a non-interactive algorithm. So the way we are going to do it is through something which we call equivocal commitments. So I'm going to describe what an equivocal commitment is. An equivocal commitment takes a commitment, which takes in a security parameter and a bit, and outputs a commitment sigma and a decommitment string D. The opening algorithm takes a commitment sigma and the decommitment string D and outputs either 0, 1, or BOT, where BOT indicates an unsuccessful open. So these equivocal commitments have an additional equivocation property which, given the security parameter, outputs a commitment string sigma and two openings D0 and D1 such that D0 opens sigma to 0 and D1 opens sigma to 1. So basically you have the capability to open your sealed envelope to two different messages. And this breaks binding. So what we have is that this equivocation algorithm is going to be an inefficient algorithm. And this equivocal commitment scheme is going to be secure against all efficient adversaries. And the equivocation algorithm is going to run in non-efficient time. And these can be constructed from the key list collision risk and hash function. This was one of the ingredients that I mentioned. And these do not require any setup. And you can build sort of these commitments naturally from such an object. So let me start with how our construction works. Our construction wishes to commit to a message M. So it samples a PRGC and it outputs a one-time pad of M with Z0. And now you want to give information to the seed. So the way you give information to the seed is you're going to have two options for every tag. So in this setting, we are amplifying from 4n to 2 to the power n tags. And for each of this sort of 2n tags, we are going to have two possibilities where if S1 is equal to 0, then I'm going to indicate that the relevant information is in the upper tag. And on the bottom tag, there is no relevant information. Similarly, if Sn is equal to 1, I'm going to indicate that the relevant information is at bottom. And at the top, there is no relevant information. So n small n here is the length of the PRG input. Then I'm going to output an equivocal commitment of this S1. And Sigma 1 is my committed equivocal commitment. And Y1 is the decommittment string. So I'm going to indicate that there's some relevant information by committing to this Y1 at the top. Similarly, I'm going to commit to Yn at the bottom here. This is almost our construction. There is additional sort of tying of randomness which is needed for construction to work. And this uses a larger PRG. So let's imagine that we have a bigger PRG that takes in a seed and outputs a very, very large string where it's still polynomial, but it outputs like n times small and many extra values. And these randomness are what we're going to use to commit our commitment algorithm at the top. And similarly at the bottom, we are going to use the randomness that we get from the PRG. So this is our complete construction. Let's see how our VAL algorithm works. Our VAL algorithm is going to open to one particular block and seeing the opening to one block, it sees Y1. And since it sees Y1, it's able to open the equivocal commitment and get the underlying seed in this equivocal commitment. So it gets some candidate S1 dash. And let's say it opened to something which was no, then it simply sets its SN dash to one. So it's opening to something which is not valid. It will not be able to open the equivocal commitment scheme. So it just simply sets SN dash to one. And then after we found this candidate PRG, we are going to run this and get these Z0 dash and Zn dash, these extra randomness. And the next phase of the VAL algorithm will be a check phase, where we're going to check that each one of these commitments at the top are well formed. In the case of SN dash being one, each of these commitments at the bottom are well formed. So this is how the VAL algorithm works. And in the end, if all of these checks pass, we output the one-time map pad of Z0 dash with the commitment string. So how does our proof work? Our proof works very similar to the DDM Isaac proof. Recall that here the VAL article goes in two phases, where one is a search phase after which it founds like a candidate C. And then it does a check on this candidate C. So now I'm going to do the same, but recall that first, I was just opening the first block, but now I'm going to open the ith block, where as argued in the Isaac scheme, the ith block is going to be different from the challenge block, the challenge tag. So let's say the seed that I found here is one, and then I do a check phase. The adversity notices the difference between these two games if the seeds were different. So let's imagine without loss of generality that the seed that you found here was in position zero, and the seed that you found here is in position one. And let's say that the check passes. Let's see what happens. If the check passes here, it means that what you found is an opening to an equivocal commitment, where Y1 is an opening to sigma 1, and S0 is the seed that you committed to. And similarly over here, you found sigma 1 as the equivocal commitment, where Y1 double dash is the opening, and you've committed to S of 1. And note that S of 0 is different from S of 1. So we've committed to both 0 and a 1. And we've precisely broken the security of the equivocal commitment scheme. And this is something that is not possible, and thus relying on this security, we can make this change. So now after we've sort of changed our val oracle, in the NISIC proof, we were able to use the small commitment scheme security to make these make changes and remove information about M. So the way we remove information about M here is instead of removing information, we add noise. And the way we add noise is we add noise to the seed. So this hinting mechanism, we'll try to obfuscate this hinting mechanism. So the way we do it is instead of running this equivocal algorithm, I'm going to run this equivocate procedure such that Y1 is a decommitment on 0 to sigma 1, and Y1 dash is a decommitment to 1 on sigma 1. Then I'm going to rely on the small commitment security to change these values. And after I've changed these values, I've removed some information about the seed. Note that you have to run equivocate algorithm, which is an inefficient algorithm to make this change. But underlying a small commitment scheme is actually going to be secure against non-uniform adversaries. So the way we are going to generate these equivocations is through the advice string and the reduction getting this advice string. So now note that there's still some information remaining about the seed, and the information remaining is in these random values. So we want to remove this information. And this is precisely what is guaranteed by a hinting PRG. So let me explain what a hinting PRG is. A hinting PRG is a special kind of a PRG where given a seed, let's say you've output a lot of these strings, and you've arranged them in this particular manner where if your first bit of the seed was 0, then the output of the PRG is going to be placed at the top. And output at the bottom is going to be a truly random string. And similarly, if the last bit of the seed is 1, the output of the PRG is at the bottom, and at the top it's a truly random string. So the hinting PRG allows you to change the output of the PRG from something which is hinting to something which is completely random. And after making sort of removing this information, there is nothing about the seed security game that remains. And then we can sort of use one-time security to say that the adversity cannot win with more than half probability. So this is our main result. And I just want to point out here that there's a caveat that we go from something that is again secure against non-uniform adversaries to something which is secure against uniform adversaries. And we define something which goes from let's say log, log, lambda to log, lambda. So note that if you get something which is secure against uniform adversaries, you cannot use this recursion multiple times. So we actually in the paper, we define a new notion which we call computation-enabled security, which is a notion which is sort of midway between a non-uniform and a uniform adversary. And we use this sort of computationally-enabled notion to perform the recursion steps. Quickly some open questions. So one of the open questions that we will want is to, can we extend this sort of framework of using hinting PRGs to remove NISICs or proofs of consistency? Can we remove the assumption of hinting PRGs to something which is simpler, like a very recent paper which constructed CCI-secure public key encryption from injective drafter functions? And additionally, can we remove the collision-resistant hash function to something which is simpler? So there's a recent work by Karana, which you replace the collision-resistant hash function assumption with obfuscation. So maybe obfuscation is too strong. And can we hope to get relaxed with this even more? So thank you and have a good day.