 All right, let's start. So what I want to do in this lecture is give the ideas, some of the ideas, in another kind of crypto foundations kind of result, saying that from any one-way function, you can construct a statistically hiding commitment scheme. This will be more high level than done in a less technical way than what we did for pseudo-random generators. But the main kind of takeaway message I want to convey is that there is yet another notion of computational entropy that is key in this result. And it differs a lot in some ways from the notions of computational entropy that we've been looking at so far. And the hope is coming out of this sequence of lectures that when you're encountering a new cryptographic problem, maybe a question that you'll start asking yourself is, is there some notion of computational entropy that captures what I'm looking for or seems related to what I'm looking for? And can it be useful in helping me construct what I want to construct? And you'll see kind of how I think in this example of statistically hiding commitments, thinking about the end goal leads us to think about a different notion of computational entropy. And as a warm-up to the notion of computational entropy that we'll be using, I think it's nice to review an older result of Damgard, Peterson, Fitzman from the maybe mid or early, mid-80s, late-80s, showing how to construct and statistically hiding commitments from collision-resistant hash functions. And it's a construction that maybe many of you have seen. It's very simple, very elegant, but will point us in the right direction. OK, so we have a commitment scheme. So as a sender and a receiver, the sender has some message, which you could think of as a, it could be an individual, a single bit. And there's first commit phase. And all right, so what the receiver does in the commit phase is chooses a hash function from a family of collision-resistant hash functions. So h, let's say, takes n-bit strings to n minus k, so it shrinks by k bits, sends h to the sender. And now the sender picks a uniformly random value in 0, 1 to the n, sends y, which is h of r. Actually, maybe I should call this, no, keep it r. Think about, yeah, I don't want to change that to x. All right, so sends y. And then to now, to send the message, picks a random seed for an extractor and sends the seed together with the extractor on r with seed s and uses that as a one-time pad to mask the message. That's the commit phase. And the reveal phase is the sender sends r, I guess. Is that all that's needed? And the message, right? So you reveal the message. And the sender reveals this random value. And then the receiver checks that is this random value consistent with what was sent here in the third message. So let's see why this construction works and just create a little more space. So we need to show two things. Let's start with statistical hiding. So hiding information theoretically, even against unbounded receivers. I'm not going to worry about cheating. This protocol is secure also against malicious receivers. But the way I let's just assume the receiver is honest but curious. So in the language that we are using, so we've revealed n minus k bits of information about r here. So if I look at the entropy, the main entropy of r, given the hash function and this is unfortunate. I wanted the hash function to be a random variable. So I want to make it capital. But then it looks like maybe I'll just use lowercase for the hash function even though it's a random variable. I'm not sure I can make my script h distinguishable enough. So this thing has at least k bits of randomness. It's an originally uniformly random n bit string. We've revealed n minus k bits of information. The chain rule for mean entropy, this information theory of mean entropy, says that it still has k bits of mean entropy, which implies that if we use the extractor as a k epsilon extractor, then if I look at h, h of r, the seed of the extractor and the extractor with r and s is epsilon close to n. And this information theoretically, s, u, m, where m is the output length of the extractor. So the parameter, the extractor, should be designed for mean entropy, which is exactly how much the hash function shrinks. And then if we, so what the receiver sees is the extractor, XOR the message. And so if we XOR the message here, that's going to be statistically close to XORing the message with the uniform and by security of the one-time pad. I mean, so this is still uniform when you XOR with a uniform with a message. And so the receiver's view is the same statistically close regardless of the message. All right. So that's statistical hiding and computational binding. So now we have a cheating sender. We want to say that the sender can't reveal two different messages. So the sender sends, doesn't need to follow the protocol. So it sends some value, Y star, in this message. It need not be obtained by hashing a value r, constructs it in possibly some other way. And then it sends some value here. So the point is for the sender to be able to open the commitment in two ways, it needs to be able to reveal two different values r and r prime that are consistent with the commit phase. That's what it means. To break the commitment means I can reveal one message with some string r. But I could also, if I wanted to change my mind, I could produce another message that's consistent with some other r prime. Because to change the message, the only way I can change the message is by changing the value of r and still to be consistent with the protocol. r and the transcript of the commit phase determine the message. So really, the sender's task is to produce two different r's that are consistent with the commit phase. So the collision resistance of the hash function tells us that the sender, the cheating sender, cannot produce two values r and r prime that are consistent with the Y star that it sent. So that's the property of a collision resistant hash function. What does it mean to be consistent? The receiver should be checking that whatever value is produced here hashes to the second message that was sent. And so to produce two different r's, you have to find a collision in the hash function. So let's think of it as follows. So instead of having the receiver, the sender, the cheating sender produce two different, separately produced two values. Let's imagine what the sender is doing is producing some random variable r star here. And so if it can produce two different values, it can produce an r star that has at least one bit of entropy with probability half as one value and probability half as the other value. So I want to rephrase this as the entropy for every cheating sender, poly-sized sender star, the entropy of r star given not just Y star, but given the state of the sender after the commit phase is negligible in n. So we've already shown computational binding. You can just see in terms of the collision resistance property. But I want to rephrase it in an entropy theoretic language. And the entropy theoretic language, I want to say, is if we can consider the entropy that the sender can produce in r star, where it's restricted to producing a consistent in r star that's consistent with the transcript of the commit phase that the receiver would accept, the sender cannot achieve non-negligible entropy. It's really stuck to a single value. Because if it could achieve non-negligible entropy, it could produce by sampling twice with non-negligible probability, it would find two different values of r that are consistent, meaning they hash to the same value, breaking the collision resistance property. So let me just, again, what's that? You can't see. All right, so this thing, I'll draw an arrow. I want to replace this state of the sender. I just want to think, what is the state of the sender? So it's h, and let's say the coins used to produce Y star. I mean, there's the h, which is chosen by the receiver. And then the sender doesn't have to follow the protocol. But in some way, it uses some coin tosses to generate a string Y star. Yes? No, no, here I really mean negligible entropy. What? The entropy is negligible. Yeah, so good. So the entropy of a random variable z, if it's at most p, where p, now I think of p as close to 0. OK, so p is a small number. This implies that there exists some fixed value, such that probability z is different from this fixed value. What function of p should go there? I think this is order p. Maybe it's even just p. And then there's some function that's going to 0 with p. And conversely, if I have, let's say this value is q, this implies that the entropy of z is at most q log, order q log. So p and q are less than a half, let's say. So having negligible entropy is the same thing as saying you're equal to some fixed value with all but negligible probability. There is some loss. It's not exactly quantitatively. It's not exactly the same thing. But the loss is only some logarithmic factor, I believe. So this statement here is, I think, what's called Fanot's lemma in information theory. Or maybe this one is Fanot's lemma, and the other one is kind of a converse to it. OK, so what do we have there? Again, so the entropy of r, if I generate it properly, given the hash function and the output y is at least k, but for any cheating sender that remains consistent with the protocol, the entropy of r star and the coins used to generate y star is negligible. So we see that what is underlying this construction is some kind of an entropy gap. If you generate r properly, the real entropy is large. But this entropy is, so this is information theoretically, but this entropy is inaccessible to any efficient algorithm. Meaning if an efficient algorithm generates a y star in some way, there may be a lot of choices for r that are consistent to it. There may be a lot of inputs to the collision resistant hash function that map to y star. In general, there will be. But nevertheless, an efficient algorithm can't sample with any non-negligible entropy from that set. So there may be 2 to the k possible values, but still it's going to be stuck with a single one. So the real entropy is large, but it's not accessible to any efficient algorithm. So this is different than all of the pseudo entropy notions, computational notions of entropy that we've been looking at because the relationship between real entropy and the computational analog is in the reverse direction. So in all the notions we've been looking at so far, like when we talk about Hill's pseudo entropy or unpredictability entropy or all of these notions, what we're interested in is that a random variable looks like it has much more entropy than it actually does. So the computational entropy is much higher than the actual entropy. Here, where we're trying to capture not in the end pseudo randomness, which is often used for secrecy and encryption, we're trying to capture a binding and unforgibility kind of property. We actually want the reverse. So there is a lot of entropy, but computationally, it's as if there is very little entropy. So yeah, that's true. So good, there's this flip between observing and generating. So in pseudo entropy and Hill's pseudo entropy and also when we talk about secrecy of encryption, the adversary is an observer. The honest parties generate something, and that should be indistinguishable to uniform to the adversary that's observing. Here, the role that the adversary is playing is trying to generate the random variables itself in a different way, but still consistent, something that looks consistent with the way the random variables would be honestly generated. In this case, consistent means that you're generating something that's a pre-image. If I hash this value, it would give the same output that I produced before. So that's also a switch that happens here. So I want to abstract this idea of accessible entropy, write it more precisely. So we have a generator. So g is going to be some poly-time generator. And it may get some, this is only just to be able to capture the collision resistant example in the framework, and the end will throw this away. There may be some public parameters. In the case of that example, you can think of the collision resistant hash function as some public parameters. I'll even just call it h here. Actually, let me call it z. And z, the generator now internally tosses some coins r and produces a sequence of values. And we define the real. All right, so again, we move from one value to a sequence of values. That won't be necessary for capturing collision resistant hash functions. But when we do something from one-way functions, we will want to break things into short pieces just like we did when we wanted to get pseudo-entropy from one-way functions. We'll do something very similar here. So we define the real entropy of g to be the sum from i going from 1 to m of the entropy of yi given z and the prefix, which is just equal to the entropy of the sequence y given z. But I want to, by the chain rule, this is Shannon entropy again. But I want to think of it as broken into the sum. So now for accessible entropy, we say that g has accessible entropy at most k if for every poly size g star, all right now, so what is a generator g star? All right, so it still gets the public parameters generated in the same z in the same way as here, because that's external. But it doesn't need to follow the way g works. So it tosses some coins, call it s1, and then uses that to generate the first block, y1. Then it tosses some coins s2, uses that to generate the second block, y2, and then tosses some coins sm, and uses that to generate the last block. And g star, what we say, so the accessible entropy is at most k, if for every such g star, if I sum the entropies of the yi's, but now it's not going to be conditioned, so it'll condition on z, but it won't condition on the previous y's. I will condition, maybe I should call these y stars for consistency, all right, this is a y star. I will condition on the coins that the generator g star used to generate the previous values, OK? So it's kind of like the coins are capturing the state of this generator. So this is like an adversary that's working online. And at every step, it's trying to generate a value, so I have to put a constraint. G star has to be consistent with g, I'll add that constraint. But every stage is trying to generate a value with as high entropy as possible, OK? It's trying to generate a y1, which has this high entropy. And now it's trying to generate a y2 that has as high entropy as possible, but given its current state, given everything it knew before, so it has to toss some fresh coins to generate anything with any entropy. So the constraint, I mean, of course, right now I haven't put any constraint on g star. Why can't it just toss lots of coins and output them? So the thing I forgot to write here is that g star has to be what we call g consistent, all right? And what does g consistent mean? We require that the support of the output of g star is contained in the support of the output of g, right? So all the sequences g star produces have to be ones that g could have produced. Yes, because otherwise, you couldn't have any entropy. If I'm conditioning on the, let's say that all the coins were just in s1, well, as soon as I condition on s1, the entropy is 0, right? So think of the collision resistant hash function or the statistically hiding commitment example. The additional randomness in the reveal phase is the sender saying, I have these two possible values that I can output, and I can get one bit of entropy by tossing a coin and doing one value with half probability and the other value with the other half probability. Great, thank you. So that's the next comment I wanted to make, but I probably would have forgotten. So this is really a computational notion. So we are interested in the fact that when k is smaller than the real entropy. Ideally, k much smaller than the real entropy. And what Yevgeny is commenting is that if we allow an computationally unbounded g star, it can achieve accessible entropy that's as high as the real entropy. How does it do it? As Yevgeny said, at each stage, it generates yi star exactly from the conditional distribution of yi given the previous outputs. So it's mimicking the distribution of g, but it's working in a different way because it's using additional randomness at each step to generate from the conditional distribution, whereas the actual efficient g tosses its coins all at once, and then that determines the whole sequence. OK, so what are some constructions of this? So one is what we just saw from a collision-resistant hash function. That's just the example. Our generator g uses its coin tosses r, and it just outputs one block, y1, which is h of r. That's the whole thing. As we said, the accessible entropy is negligible, but the real entropy is at least the input length minus the output length of the collision-resistant hash function. So it's at least k's, unfortunately, different k than here. It's the input length minus the output length of the collision-resistant hash function. All right, how about from a one-way function? That's just the name we came up with. So there is entropy, again, so we're saying intuitively there is entropy in the input to a collision-resistant hash function conditioned on the output, but it's hard to access that entropy. It's infeasible to generate things with that kind of entropy. I don't know if you have a suggestion for a name that fits that better. I think it's not too late for us. I don't know. Maybe there has been a journal version already. I don't remember. All right, so how about from one-way functions? So it turns out something very similar to the way we got pseudo-entropy from one-way functions will work. There won't be any public parameters in this case. Our generator G chooses a random input to the one-way function, call it x, and it outputs the bits of f of x one at a time, and then in its last block it outputs x. These are the blocks, and these actually don't have to be individual bits. They could be logarithmic length also. The thing to note, and I'll give some idea about why this should be, all right, so the claim, the real entropy, is n, because everything is determined by x, and we do reveal x, so the total entropy in the output is n bits of entropy. And the claim is that the accessible entropy is at most n minus little omega of log n. Ah, yes, yes, yes. Oh, sorry, sorry, there are two blocks. Sorry, so this should be y2 is r. Thank you. And now the real entropy, sorry. All right, so it's thanks. The entropy of y1 is the output length of the collision resistant hash function, and the entropy of the second thing is n minus k plus k, which is n. OK, good. And this thing here, thank you, sorry about that, is n is the output length, which is n minus k, plus negligible. For accessible entropy, it's important. So accessible entropy, you have to, like you commit yourself to the earlier blocks, you commit yourself by producing the earlier blocks, and now I want to measure the entropy that you can produce in the next block conditioned on the previous ones, conditioned on my state after generating the previous ones. So I have to put y1, the output of the hash function, as the first block, because my gap in entropies on y2 comes only conditioned on producing y1, the state of G star that was used to produce y1. Oh, just to match these two terms. Just to match the definition here, I have the sum of the terms, right? But in total, it's just n. Ah, yes, OK, thanks. I don't need that. Where's the eraser? Does anyone see the eraser? There should be entropy of, let me just write n. It's not, those two terms are not exactly that value. Ah, thank you, thank you. OK, good. Sorry, quite confused. All right, good. So sorry about that mistake. Did anyone, anyone want me to explain, just raise your hand if you want me to explain this again since I got it wrong the first time? Please explain it. So, good. So imagine, all right, so the real entropy being n is, the real entropy being n is just because everything is determined by r, right? r, we're conditioning always on the public parameters, h. And so the entropy of all the output is given by the entropy of r. And r is uniform in the honest generator. It's an n-bit string. But for the accessible entropy, so now we have a g star that tosses some coins, s1 produces a y1 star, and then tosses some new coins, s2 and produces a y2 star. OK, and we're looking at the entropy of y1 star given the hash function plus the entropy of y2 star, let's call it r star, r star given the hash function and y1 star. This first term is at most n minus k because the length of y1 star is n minus k. The second term is negligible, not y1 star, sorry, this should be s1, the coin tosses, right? We condition on the coin tosses. The second term is negligible by collision resistant. Collision resistant. So given the state of g star after generating y1 star, it is bound to a single value. It can't find two values of r star except with negligible probability that are consistent. And remember, we're restricting to generators that are consistent. So that means that our star, it produces, has to be a pre-image of y1 star. Good, good, thanks. So you're right, in all the construction, I mean, the only two constructions we're going to talk about are these two. In all of these, the last block is actually the coin tosses of the honest algorithm, right? And so you can verify, once you've seen the last block, you can efficiently verify that everything is consistent. Okay? All right, so we do have a more general definition which doesn't restrict to generators that are consistent. And instead, somehow discounts the entropy when you produce something that's inconsistent. All is consistent with what the rise of M is equal to R. And then, So, I... I'm not sure, maybe it is. So the place where we need really the more general definition is when we talk about inaccessible entropy of protocols rather than just these generators. And we have some other application of inaccessible entropy where we show that constant round zero knowledge proofs, maybe with black box simulation. I don't know, some kind of constant round zero knowledge proofs with navigable error imply constant round statistically hiding commitments. Okay? And there, we also go through inaccessible entropy, but we need a more general and more complicated notion. We've trimmed down the notion for this application. It possibly could be trimmed down even more to only talk about generators where the last thing is coin tosses. The other application needs more generality, but even a lot more than this. All right, so let's talk about why one-way functions, why this construction, intuitively, oh, so I wanna compare this. This is, looks very similar to our pseudo entropy generator from one-way functions. The one that got the gap between hill, pseudo entropy, next bit hill, pseudo entropy, and actual entropy. Anyone notice what the difference is? Right, so in the pseudo entropy generator, we output f of x as one block, and then we split x into individual blocks. And we said that the hardness of inverting f implies that the bits of x, if you look at them one at a time, do have in total more pseudo entropy than the actual entropy, right? And here, we are splitting the bits of f into bits, and we output x as a chunk in its whole. And it seems to be that there's some kind of duality between these notions. Certainly the construction seems to have this duality, but I don't know any way of formalizing that intuition. And we'll see even more similarities between the way you use an accessible entropy generator to construct statistic hiding commitments is very similar to the way we used pseudo entropy generator, next bit pseudo entropy generator, construct pseudo random generators. All right, so why, so let's imagine we have a G star, and also notice the bound is very similar to it. Real entropy N in both cases, pseudo entropy was N plus little omega of log N. Here, we want accessible entropy is smaller than the real entropy, so it's N minus little omega of log N. All right, so we have some generator G star, all right? And it produces, let's not, let's call this Y1 star, Y2 star, YN star. And then it produces some X star, which since it's forced to be consistent, should be a pre-image of the Y, Y1 star up to YN star. Okay, so suppose G star achieves very high accessible entropy. Suppose it's almost N. Don't worry about this logarithmic factor. Suppose it really gets accessible entropy very close to N, to full entropy. Let's think about that, what does that mean? So getting full entropy in X star, I mean in the output of G star, well because of the consistency constraint, everything that G star outputs is determined by its last block, right? And the last block is only N bits long. It's the input to the one-way function. So the only way intuitively, G star can achieve entropy close to N is if X star is really actually close to uniform, which in turn, because we're measuring the entropy conditioned on previous coin tosses, means that it must be really generating all the YI stars very close to the correct conditional distribution, right? So intuitively to achieve nearly maximal accessible entropy, G star has to generate Y1 star really according to the distribution of the first bit of F of a uniformly random value. And then condition on that, it really needs to generate Y2 star according to the conditional distribution of the second bit given the first bit, and so on. And it's just intuition. I'm not going to prove, so what's that? Okay, so now how can we use that to build an inverter? All right, suppose we have such a G star. No, no, there's a one-way function. It's N bits to N bits. We're not doing collision resistant hash function anymore. Oh, sorry, this is a, thanks. No, no, it's just convenient, yeah. All right, so we want to use G star to build an inverter, all right? So the inverter is given some output Y, and now it wants to find a pre-image. So we know that G star always produces a pre-image of whatever YI star values it output in its earlier blocks. By definition, it's consistent. So the natural thing to do is to try to get G star to produce its first N blocks that agree with the point that I'm trying to invert on. Okay, so what am I going to do? Well, I can keep trying random coin tosses of G star, S1, until I get the first bit to match with Y's first bit. Now, given that, I can keep trying coin tosses S2 to try to get Y2 star to match the second bit of Y, and so on. Yes and no, so if we do log N bit, so intuitively, if these are one bit values, then I should only need a constant number of tries on average to get a match, right? If it's log N bit values, I do have less iterations, but I need more tries to get a match, right? Intuitively, I'll need polynomial many tries to get a match on the first block, and polynomial many tries to get a match on the second block, and so on. So I'm not sure in terms of the efficiency of the reduction, whether we do or do not win by doing that, but we do gain in the application, if we have fewer blocks, we'll get a better statistically hiding commitment scheme with fewer rounds. That's right, that's exactly right. All right, so we first find an S1 so that by just trying many values so that Y1 star is Y1, and then we find a S2 so that Y2 star is Y2, and so on, and if we succeed in finding all these matches at the end, G star is gonna give us a pre-image. And you can show that the success probability of this inverter that we construct from G star in this way is basically something exponential in the entropy gap here, right? So if I had entropy N minus one, N minus two, I would succeed in inverting with constant probability since I know that I can only invert with negligible probability, I get an entropy gap of little omega log N. Okay, questions, I didn't plan to do this in any more formality than this. One has to go through a proof that's not that different from what we did with the, you know, when we did the chain rule argument for the, with the KL, with the divergence, the relative entropy. Sorry. It works, it works. Yeah. Yeah, so you need to, you know, account for the fact that, okay, you know, after how many tries, what if you haven't found a match, you throw that into your failure probability, you know, these kind of usually, it just works. I mean, you have to work with entropy here in the calculations. I actually think there should be a cleaner proof of this that's more similar to the one we did before. Actually, this, I find that proof more elegant than the proof we have for this. It really is just, you know, the success probability is really just, you know, the given by this chain rule for divergence. And here it's nothing complicated but not quite as elegant. Yeah, so it can use polynomially many random bits for each thing and that's not a problem. We don't, because we only care about really the distribution, the conditional distributions on the bits that the SIs generate. No, no, so it's not brute force. It's by random sampling. We find the SIs, yes. Yeah, so we keep randomly trying values. No, it, it. No, the Ss are done as well, that's one, that's ten. Oh, oh, because to analyze, we really need that the entropies are close to the true entropies given the previous SIs. Because once you, once you've gotten the match on the first few, those SIs are fixed and now, now how G star behaves on the. We need fresh randomness in each block. Yes. All right, so what is all this good for? Constructing statistically hiding commitments. So maybe we'll go over here. So a theorem is that if we have an M block inaccessible entropy generator with a non-negligible entropy gap, all right, maybe here you've gained this application, the way I'm phrasing it right now, here maybe we do use the coins or the last block. Okay, there's some kind of verifiability that one needs here, but let me, let me just put for simplicity the coins being the last block. Basically again, that you can verify the consistency. So we do need that in this application. One can get an O of M round statistically hiding commitment scheme. All right, so the non-negligible gap. So here my entropy gap is the difference between the accessible entropy and the real entropy. So here it's not just non-negligible, here it's more than a constant, but the theorem is true, even if I had a one over poly gap between these two, you can still construct a statistically hiding commitment. You will just need to do more repetitions to amplify that gap, right? So good, so if all I care about is the number of rounds of the statistically hiding commitment, then I would get even from a very weak one way function, like where the failure to invert is only one over poly. I would still get a statistically hiding commitment with the same number of rounds, but you will pay in other kinds of efficiency in the construction, the number of invocations of the one way function, the communication complexity of the statistically hiding commitment scheme. All right, so we aren't gonna do this in any kind of detail, but I want to just say what are the overall steps. So the first step is again the same kind of what we call entropy equalization. This is to get the same entropy in every, same real entropy in every block, and maybe I will, I didn't, that was the thing at the end that I, so we had the same difficulties that we had with the pseudo entropy generator is that we don't know how the entropy split among the different blocks, and so there's some same trick that I might spend a few minutes on solves that problem here. I actually first discovered in this setting of inaccessible entropy. Then we do repetitions to do two things, amplify the entropy gap just as before and B convert Shannon entropy to end max entropy. All right, so let me be a little more clear here. So the real entropy in each block, the information theoretic entropy, what we want when we do repetitions is that this turns into min entropy because eventually we're gonna use that for, for like we did in the statistically hiding commitment from collision resistant hash functions, we're gonna use that entropy for masking our message, right, we're gonna extract from it. We wanna extract almost uniform bits from it and we can only extract almost uniform bits from min entropy. It turns out that for accessible entropy, the accessible entropy, we also want that to improve, but we want a stronger upper bound on accessible entropy, not a weaker, like since accessible entropy is an upper bound, having a stronger bound on it means we're saying it's close to having small max entropy. Meaning, not only is the sum of the Shannon entropies produced by the generator small, but actually with very high probability, each of these YI stars is contained in a small set conditioned on the previous values. Small support, it's mostly concentrated in a small support. Did max entropy come up at all in the, so max entropy really means small support and so we want to be close to low max entropy means you're concentrated in a small support. It's called an H0. H0, H0, right, so there's H infinity and there's H0, good. All right, and then the third step is the one which becomes more complicated here because we then work with the protocols. It's not just plain old randomness extraction. To do the, we do the kind of extraction in an interactive way using interactive hashing, what's some of the protocol called interactive hashing, and actually we also use here universal one-way hash functions. These are target collision resistant hash functions, a weaker form of collision resistance, which are also known to be constructable from one-way functions to get a protocol that's statistically hiding and computationally binding. All right, so the statistical hiding property comes from the real entropy, the having high real entropy in the different blocks. Again, you can kind of use that to extract and mask your message and being contained in a small support. Intuitively seems related to binding because it's just like here. So the reason that the protocol was binding when we did collision resistance hash functions is that after you give the output of the, after the sender gives the output of the collision resistance hash function, our star is basically contained to a single value, supportive size one. Okay, so this step becomes more complicated. But is in spirit very similar to the randomness extraction step of the pseudo random generator construction. And the other two steps are basically identical. So let me just say what this entropy equalization is. I think it's, okay, yeah, so here's the way we can do it. So Y1, Y2, Ym. So I'm using the suggestion who suggested to just do shifts, was it you, Woody? Yeah. So, let's see, maybe I wanna have Y1 here. Okay, so these are all independent samples of our, we run the generator many times and this is the first output, the second output, I didn't put an index in for it, but these are the many, many samples. And we arrange them in this kind of shifted way. And we take all the columns where I have one representative from each block. So after m minus one such shifts, I have a block which has Ym, Ym minus one, Ym minus two all the way down to Y1. All right, but I have to throw out these first m minus one things. And similarly, at the end, after I throw out the last m minus one copies, all the columns have exactly one representative of each block. Yes. It would be very nice too, but since these entropy notions are all kind of very dependent on the way we're measuring things on the order of the bits, it breaks down when we start reordering things. It would be nice, I don't know how to analyze that. Sure. All right, and so what's the point? If we do T copies, the entropy gap that we gain is T times, in both cases, this and the pseudo random generator construction, we gain an entropy gap of T times omega log n between the real entropy and whichever computational entropy notion we're looking at. But we lose the entropy from the blocks that we've discarded, right, which is let's say 2m times the entropy in a single block, in our cases, this was always n. Okay, so maybe this is a way in which it's more efficient to do, I think we're losing more, when we do the random shifts as opposed to this, we don't have this m here. Okay, so this is a little bit more expensive. But if you were combining it with the other step, then I think it's fine. But if you wanna separate the two steps cleanly, it's better to do random shift. But this is easier to see visually. All right, and so the point is that if we take T big enough, the win in entropy gap defeats the loss that comes from the columns that we discard. Okay, we're gonna discard these columns. Why are we discarding these columns? In all these other columns, we know exactly how much entropy there is because we have one representative of each block. Our real entropy is really at least the sum of the entropies in the individual blocks. Okay, so that's this entropy equalization trip, which I mentioned for the pseudo-random generators also applies here. Okay, so I think that's all I wanna say about this proof. So maybe it's a good time to stop for questions. So the protocol doesn't have as simple a description as what like the pseudo-random generator because this interactive hashing step is, this is, it's kind of complicated. The sender, let's see, maybe if I go over here to the generator. So all right, so let's think about what happened with the statistically hiding commitment from collision resistance and hash function. First, the sender sent the first block, okay? And then we knew we had an entropy, in this case the entropy gap was always occurring between accessible and real, it was always occurring in the second block. And so we use this as the value which we extract the real entropy to hide the message, but the low accessible entropy is what makes it binding against the bounded sender. So we wanna do the same thing here. The protocol is gonna proceed in m phases, each one constant number of rounds. At the end of the first phase, y one will have been revealed, by the end of the second phase, y two will have been revealed, the end of the last phase, y m will have been revealed. And the receiver is gonna pick randomly which one we use for the actual commitment. Okay, so we know that any cheating sender somewhere must have a accessible entropy in a particular block that's smaller than the actual entropy. Okay, and so that if we can find that block where the sender fails to achieve high entropy, that is gonna be good for doing a commitment the same way that we could extract, we use the input to the collision resistant hash function for commitment. No, so the thing that makes it complicated is a cheating generator, which is a cheating sender, can decide adaptively on the fly which block to cheat in, which one to try to achieve the high entropy. Okay, and so that's where the additional work comes in and just having the receiver choose it at random turns out not to be in itself enough because if the sender knows that value, it'll decide to cheat in a different block. And so that's where some of the additional complication of this interactive hashing protocols comes in to kind of make the force the sender to decide at the start of a block whether it's going to cheat in that block or not. Do you think the issue interactive structure, I know that the block number would want something, the gap is between like 15 and 25, what would be the analogous stuff if you use extractor? You can still use extractor, well no, you still would need some kind of interactive hashing. So interactive hashing, this is what's so-called constant round interactive hashing, the information theoretic interactive hashing, that's needed even for the setting that you describe, okay? The universal one-way hash function, so that the interactive hashing has the property that it'll take your 15 bits of accessible entropy, turn that to zero or negligible and your large amount of accessible entropy, turn that to something statistically close to uniform that will mask the message. The universal one-way hash function is what's used to force the sender somehow to commit to which round it's going to break at the start of, commit at the start of a round, start of a phase. So really, I mean, I don't know that the need I'm asking, I'm asking. Yes, yes, you know, the thing that's a little, if we know the block number, then we don't need many blocks, we could just collapse this whole thing to two blocks. All right, and then we really sort of turn back to this and then you could say in this setting, if all we knew was accessible entropy here as opposed to negligible versus large, then you can use interactive hashing to build a statistical hiding commitment. That's right. Is it, you know, more clean and natural, the 15, 25 things, like the constant round thing? It's pretty simple. It's just two rounds of hash functions. There's a little bit of interaction. That's a little bit of a metric. It's information theoretic, yeah. It's a very nice protocol. The one we use is... Ding, Harnick, Rosen and Cheltiel from TCC some 10 years ago or something. All right, any other questions? All right, so maybe now I think there's, I don't have anything to write. I think the takeaway message again is that, I mean, maybe we've known for a long time that pseudo entropy in some way is useful in these settings where eventually you want to get to pseudo randomness, you want to use it to eventually do some kind of encryption, derive a key, and so on, right? We knew back from Hill that having a computational analog of entropy is a kind of more qualitative, a quantitative measure of randomness, computational randomness was useful, right? We start out, pseudo randomness is useful because it is talking about being indistinguishable from having maximum entropy, and pseudo entropy, hill pseudo entropy is a quantitative version. It says, well, not just that you're indistinguishable from maximal entropy, it's also interesting to talk about being indistinguishable from having some large entropy, even if it's not maxible. And I think a takeaway message from the, kind of probably the many of the talks is, there is not only one way of talking about computational kind of quantitative versions of computational entropy, but there are many others that are suitable that come up naturally in different applications like leakage-resilient crypto, like in constructing pseudo random generators, so on. And then these are often useful as an intermediate step towards the end goal of pseudo randomness, driving a key, and so on. Here the message is that there are, for other types of cryptographic security properties such as this computational binding property where the task of the adversary is not to distinguish, is not an observer, but is supposed to try to generate something, the adversary is trying to generate something that's not supposed to generate a decommitment to two different messages. There, it is also fruitful to introduce quantitative computational entropy measures. And so this is just one, I mean this I think is one example, but I expect that if one is looking for this elsewhere in the crypto literature, in the types of problems we look at, one would find other places where it is fruitful to introduce some kind of quantitative computational entropy measure as a stepping stone towards some security property that you're interested in. Yeah? And then when you look at this linear loop, the same problem that you were thinking of, computational versions of PDAs and interrelations with the building, the problem, et cetera. And there, you could also think of a computational analysis that means a single solution to be a site that actually turns out to be what's useful for anything that is un-portability. So in fact, the useful thing is another problem which is of this kind, a flexible, it's called a flexible problem. And we try to informally write these in production, yes, match with un-portability notion, but we didn't know how to put a hand on that. That sounds great. What's the, maybe the title of the paper or something? The other people are? Colonel Assumptions, great. So, great to hear. So yeah, so we, after this inaccessible entropy work, we, you know, wondered, certainly wondered whether there are other places we're thinking in this way, it could be useful, but we didn't actually really follow up on that. And so I'm happy to hear there are places which already seem to be looking at quantitative notions that generalize un-fortability. One thing we did try to do was also simplify and improve the construction of universal one-way hash functions, these target collision resistant hash functions from one-way functions. This is the classic result of Rampol, also quite complicated. And we were able to do something there, but it hasn't, it didn't turn out to be quite as clean as a modular, oh yeah, I guess it's modular, but it's not, some of the things don't work out as nicely as they do in the statistically hiding commitment case, and I don't really understand why. So it feels like we didn't hit, we use some variant of inaccessible entropy here as a stepping stone to build universal one-way hash functions, because that's also kind of like a, you know, un-fortability property, but it feels to me that we haven't gotten the right, exactly the right notion there. And so there probably are other settings as well where trying to find the right, computational analog of entropy can lead to either simplifications or improvements. And this may be one, yep. So what you can just, if I say about three, four, I mean, I make a parameter, it's just like all different complexity assumptions, you know, from, you know, three you can achieve two, and from four you can achieve three, and there is like a hierarchy of assumptions from one-way functions to two. So it's a good question. I don't even know for two, I'm not sure that it's equivalent to collision-resistant hash functions. There's already some, I forget which paper, maybe there is some paper that introduces some generalization of collision-resistant hash functions that are already enough for doing statistically hiding commitments in a similar way here that seem to be, at least it's not known that they're equivalent to collision-resistant hash functions and maybe there's some kind of separation there. So if that's known, it might have been along Rosen and maybe Odette Goldreich and others, but I'm not remembering for sure. We do know there's a black-box separation between constant rounds and polynomially many rounds because there is this lower bound of Hatener, Haak, Segev, Rheingold and Segev that says to do statistically hiding commitments from general one-way functions, you need n over log n rounds, omega of n over log n, which matches what we achieve here with this construction in a black-box, to do it in a black-box way. And so in particular, you can't get constant rounds from an arbitrary one-way function. And I don't know if anyone's looked at a finer hierarchy beyond constant versus linear. So more, I mean, more, kind of, in a particular consumer, I'm not sure, I mean, historically, than maybe the statistically hiding commitments with the right application, but to me, the heart of what you're doing, if you ignore the privacy gimmick, is really building an interactive solution-resistant hash function where you only count communication from the center of the receiver, and you just want to say, I want to commit meaning finding and not care about hiding, but it's a gimmick that you can kind of achieve. Great, so now that you say that, maybe that's even the notion that was introduced in this paper. I don't remember that I'm talking about. Goldreich, Rosen, others, I'm not sure. That is how I think of what we're doing in the construction of statistically hiding, is somehow trying to build some interactive version of collision-resistant hash functions. One can maybe think of a statistically hiding commitment scheme that way in general. I hope that you want to do one round, if you don't count properly, but you know, two rounds, that's just like four, whatever, three, four. To me, my conjecture is it seems to be a three-parer here, but I don't know if it's going to be interesting to do that. Yeah, I agree, I agree. Yes, we'll go. So we're making that maybe a little time in the process in that sense, wondering whether that separation is that based on entropy? Based on entropy. Is there a reason about the separation? I think one can think some of these efficiency lower bounds, like the Genaro-Trevison lower bounds saying that, you know, the number of invocations of a one-way function that you need to build a pseudo-random generator, is at least the stretch of the generator divided by log of the security, and even for one-way permutations, right? And I think what's going on there is some kind of entropy reasoning, though I don't know that it's the same kind of entropy. I haven't tried to match it up with the same kinds of entropy notions that we're looking at here. But it's a good question, and certainly the way that I'm, when I ask these questions about, can we show a super linear lower bound on the seed length of pseudo-random generators from one-way functions and so on, the approach that I would take is kind of trying to reason in a computation, in a kind of entropy theoretic way. No, I think so there, yes. I mean, it is known that there is a separate, there is a black-box separation between one-way functions and injective one-way functions. I said there was originally some conjecture of Roudich which was about one-way permutations, and then the conjecture was proven, there was something mathematical combinatorial conjecture that was proven by Khan et al, Khan and Sax and someone else. And then I think there's also a more recent paper of Mohamed Mahmoudi and Rafael Paz, if I'm remembering correctly, that I think either as a corollary, maybe it's known in other ways, as a corollary separates one-way functions from injective one-way functions for black-box constructions. That would make life a lot simpler. If we could just convert a one-way function to an injective one-way function, we wouldn't need to do all this work. From injective one-way functions. Yeah, great. All right, so I think now it's probably a good time to break. Let me see if there's any last remarks I want to make. I wouldn't expect that after the series of lectures that you're all going to remember all these different entropy notions and how they relate to each other, what setting they're useful, but I think hopefully the thing that you take away is that they exist, that there are, and that, you know, there's some of the kinds of subtleties that arise, and just because one entropy notion isn't the right thing for you, there's a catalog of other ones that you could look at and try to match to your needs in a particular application. All right, so why don't we end there?