 Thanks, Dash, for the introduction and good morning, everyone. I'm going to talk about how to deal with subverted hash function. The title of my talk is Correcting Subverted Random Oracles, and I'm Chang, this is joined work with Alex Russell, Moti Yang, and Hongsheng Zhou. We all love hash functions, which is one of the most widely used cryptographic tools in practice. And we know that it can be used for password logging, digital signatures, and also blockchain. And this blockchain means both blockchain and blockchain, and many more. And also we have a bunch of, we actually have a couple of candidates that can be assumed as a random oracle when we use the hash function, as long as you don't insist on still using MD5. On the other hand, the hash designs are fairly complex. Especially for non-experts like me, I don't really want to implement the hash from scratch. It's very easy to make mistakes. But luckily, for the experts on the hash function, the actual implementation can be optimized in various ways, for example, designing special algorithms, or even using dedicated hardware. So it's quite common when we really use hash function in practice. We simply go to some famous library, or we even just buy some hardware. This is actually a real mining machine, packed a lot of GPUs inside. So then a natural question arises. When you think you are using SHA256, how do you really make sure you are really using SHA256? I think about this question seems a little bit complicated. So this whole question motivates our work to deal with potential subverted hash function. So in this talk, I will briefly introduce a couple of simple but devastating attacks while hash subversion. And then we will introduce formal definition, or what do we mean by correcting a subverted random oracle. I hope we can slowly explain the construction step by step and lead to our design idea, then give you some high-level idea about the actual complex security analysis. So let's get back to the basic scenario. Say I'm a user, I want to use some hash function according to some specifications, say SHA256. Then I simply send a request to an implementation provider. The implementation provider here is considered as actual an attacker. So he will send back a real implementation, but which could be potentially subverted. And sometimes we call it crooked according to whoever's standard. Obviously, if the subversion is done arbitrarily, say the hash implementation actually just output all zero or all one, it's very easy for the user to notice something is wrong with the hash implementation. But the attacker could be more careful. Consider a special implementation contains some bugs or maybe backdoors. We call it hidden trigger here. When the trigger is actually pulled by the implementation provider, then the implementation is going to return something very nice to the attacker. While on other times, or when the hash implementation is used by other users, it actually facefully evaluates essentially almost everywhere. So the implementation is actually correct on overwhelming portion of inputs. So in this way, no one can detect such subversion by black box testing. Some of you might wonder, is this simple attack really reasonable? So first, the attacker prefers to keep the subversion undetectable. Well, that's easily understandable because if easily noticeable, then the user simply discard the implementation. And we call such kind of attacker malicious but proud. And this also echoes the classical theory of kleptography in which the adversary tries to steal information while black or via subverted implementation but won't steal in a subliminal way. But what is worse is that these evasive triggers actually are devastating enough. Let's see a very concrete example in blockchain. This is a real blockchain. So normally, let's consider a simple, a more common proof work based on blockchain and the miners just work a hash implementation and work their heart, try to find a puzzle solution in order to generate a new block. So once he indeed worked a lot of times and find a puzzle solution, he packs the puzzle solution into the new block and then broadcast to all the other miners. All the other miners also have the hash implementation going to validate whether this puzzle solution is correct or not. Then decide whether to attach this new block to the current chain. Everything works perfectly. And even we have a provable secure protocol that shows proof work can indeed boost a secure consensus protocol. But there is a catch. What if the implementation of the hash is actually subverted? This question becomes more relevant, especially dominating portion of the mining machines actually come from very few number of manufacturers. Essentially, most of miners are using similar implementation of the hash function contained in the mining machine. Let's consider a simple way of croaking this hash. So we have the subverted implementation. The designer or not the designer, the implementation provider or the malicious manufacturer design a very special trigger such that if the last couple bits of the input contains a very special string that is only known to the manufacturer, this hash function simply output zero. Then what's gonna happen? The manufacturer can use such kind of malicious implementation to generate a puzzle solution very easily without doing any actual work. He can simply send the trigger input. Well, since most of the other miners also use similar implementation, they will consider such puzzle solution actually as valid. Now the manufacturer can easily generate a bunch of blocks without any effort. And then broadcast will be considered valid and easily take over the whole chain at any time, starting from anywhere as she wishes. What is worse is that no one can actually detect such subversion before actually deploying the blockchain. Because when you take the mining machine, you can do all kind of black box testing, you don't find anything. Hope now I kind of convince you that this is really a serious threat that we need to handle. And also actually similar type of tech can be applied in many other scenario as well, for example password locking. So our goal in this work is try to correct a subverted hashback. We can still inherit all the nice properties of the optimization or whatever, but we can safely and confidently deploy such a hash function in other systems. So in a high level idea, the procedure goes as follows. The attacker takes a hash specification, say shout 256, then he produced implementation, implementation could be subverted. Then the job of us is to provide a simple wrapper and still use the implementation as a core building block, but just wrap it around. And we want to make sure that after this simple wrapping, this new corrected hash function will be good even to the attacker. So what do we mean? In a high level, we want to preserve all the properties of a run oracle if the original specification is assumed to be a run oracle. So in this way, we want to clip the power of such a kleptographic attacks on the hash function. So before I explain the formal definition of what do we mean by correcting a run oracle, let me briefly introduce a couple of simple observations. So first, actually deterministic correction will never work. Why we would say so? Let's see a concrete example. Suppose the capital G is the corrected version of the hash function. And h tilde is the malicious implementation. What we're gonna do, we're gonna first pre-process the input using some function f and then post-process the output using some function g. But I will claim this can never be a run oracle. The attack is pretty simple. So the attacker gonna plan the trigger in a different way. So instead of directly putting the backdoor z at the hash implementation, he gonna choose a backdoor, but evaluate first. Then plan this value as a trigger of h tilde. Now, it's very easy, the attacker knows for sure. When the capital G evaluated this backdoor point z, it can always are equal to g zero. It's fully predictable to the adversary. Well, on the other hand, if we use, so this means we need to use randomness. But if we use private randomness, everything become trivial. So we simply shift the input. Intuitively, the input gonna be mapped to a random point. And if the malicious implementation is correct on overwhelming portion of input, a random point likely will be good. But unfortunately, this model is not realistic at all. Because hash function, especially run oracle, is a public object, which needs to be accessible by everyone, which can be evaluated by everyone. And in particular, different people evaluate at the same point. It should always return the same output. So what do we learn here? That seems the only choice we have is to use some small amount of public randomness, and this public randomness is chosen after the implementation is provided. So now we are ready to actually consider the formal definition. We want to correct a subverted implementation back to a good one, right? So we want to capture as good as. So there's a very nice framework called indifferential ability captures the ideal object in cryptography, especially the property of as good as. So how it works? So construction takes the ideal object to G, try to mimic another ideal object F. And what do we mean is the construction C gonna be as good as F is for any distinguisher, there exists a simulator. And when the distinguisher communicates with real world or ideal world, the distinguisher cannot tell them apart. And what's very nice about it that there was something called a replacement theorem was proved before that the actual construction C by Oracle access to the ideal object G actually indeed can replace ideal object F in larger systems. So we can safely just plug into other places. Now we want to model a similar thing, but now we immediately meet a trouble. So first, the construction in now setting actually don't even have direct access to the original ideal object, the original run Oracle. Because it can only access while the malicious implementation. Actually, to tailor this model to reflect in our setting, it's quite highly non-trivial. So we call the new notion crooked in differentiability, so what's the procedure? So first, the distinguisher queries the original ideal object and try to do all kind of preprocessing, prepare the back door, prepare the malicious implementation. Then he just disperse the malicious implementation and the construction comes. The construction gonna sample some public randomness and reveal the public randomness to the distinguisher. Then the distinguisher gonna intact with two words again, try to distinguish whether he's talking with the construction using the subverted implementation or still he's talking with the ideal object. And here the randomness we only use a small fixed amount. And very nicely, we also show a version, a variant of the replacement theorem we call H crooked replacement theorem. Is that the, our construction, if any construction is satisfy the crooked in this, in differentiability, we can also safely replace the ideal object in larger systems. Now with the model settled down, let's try to see how we can get the actual construction. Let's make some attempt. So first, very natural and simple idea is still we want to shift in the input right, because the trigger is contained in input. If we can map the input somehow to a random places, then we are good. But this construction obviously is easy to attack. Because the randomness here are used is public. The attacker actually knows when the attacker originally implant the backdoor Z in the edge tilde, all the attacker needs is just to find back this, this, this backdoor. He simply shift, he choose the input such that when shifted after the randomness R, he will map back to original backdoor Z. So it's very easy and trivially distinguished from this point. Let's try something more, slightly more complicated. Well, just shifting input might not be good. How about we also shift output? We also mix several items of the output. Now it seems the immediate attack won't be helpful, because even if the adversary finds the backdoor here, it's going to be shifted to some other places. Intuitively, it seems good. But actually, the attacker could just do something slightly smarter. He plans slightly more backdoors. Instead of planting one, he's going to try to divide input into half. There are going to be two types of backdoor. The first type of backdoor contains a very special string Z, as long as the first half of string is equal to Z, and it's going to be backdoor. Similarly, if the second half is equal to a special string Z, it's also backdoor. Still, there's only an exponentially small portion of the input. So in order to break, the attacker can simply find the input, satisfy that when shifted with R1, it's going to map to the first type of backdoor, force to the first part of the 40 inputs. And when shifted using R2, it's going to be forced back to the second type of backdoor. So in this way, again, he can trivially distinguish by finding such kind of input. What is worse is that this type of attack actually can be generalized. Even to suppose the length of the input is n, we can generalize this attack to n divided by security parameter, this many of terms. Even with shift and mix and shift using this many terms. The idea is actually very simple. We just cut the input into chunks and plant backdoor in each chunk. And still, the total number of backdoor is still exponentially small. This sounds quite disappointing. But the attack only generalizes to this term, this many of terms. Let's think a little bit. How about we keep adding? It seems our attack only works to this many terms. If we have more terms, would it help? This idea might sound a little bit silly from the beginning, but actually it do have some rationale behind. Because in order for the attacker to influence any value of any term, it has to pass some trigger input in. Trigger input means information. You have to burn the original bits. At least one trigger needs to burn one bits. So if the total number of bits at n, that means the attacker can at most influence n terms. So if we're mixing enough times, it seems there must exist some term that is never influenced by the malicious input. That's the hope. Then let's try to analyze whether this construction really works. It turns out the analysis is surprisingly difficult. Or maybe complex. Or maybe you guys can find a much simpler way than let me know. So with what we really want to show, we want to show that for every input x, there exists some term. But what we observe now is for every input x, there exists some term that will be honestly generated. Honestly generated means the output of this, at this particular input value, is equal to the specification. But this is not enough at all. Because the reason that this term is not changed, it might because the adversary actually want to keep it unchanged. The adversary might do a very complex rejection sampling using all of them as a whole. If the final output is something he likes, he would be happy to keep some terms unchanged. So that suggests we need to prove something more. So suppose this term is honest, we also need to prove there exists some term that is kind of independent with all any other terms. So by independent here, I mean the value of here is not influenced by any other term at all. Or to put it more concretely, when evaluate the particular input at this point, is never carried by the Rhinoceros when evaluating at any other points. That's what we want to prove. If we have these both properties, then we try to find, ensure there is a good term that satisfy both. Then we're gonna be happy. But there are two challenges remain. In order to really show such independence intuitively, we really need to examine all the values at these all points. After we expose all the possible random values, we identify some term. If we replace this term, it doesn't really influence other terms at all. And also when evaluating at all the other terms, this single input is never carried. That seems easy. But the immediate question we will face is that since we already evaluate this term, how can we still claim this is uniformly generated? And also another challenge is that we still need to finish the stimulator and inherit organized properties. For example, programmability is not clear how we can get this property. So we handle the first challenge by developing a new analytic tool. And for the second challenge, we actually need to tweak the construction a little bit more. So in order to tackle the first challenge, we develop a new analytic machinery we call rejection re-sampling them. So consider a vector of random variables and the adversary define its favorite event E and mu means the probability of this event. Then the adversary can choose arbitrary one of the random variable and re-sample it according to be a uniform according to the uniform distribution. Then this defines again another probability of the same event that adversary likes. So what we actually prove is that these two events, the two probabilities actually do not differ much. Why the re-sampling lemma is needed because we want to pretend after we evaluating at all the points we identify one good item, right? We still want to pretend originally we never see it and it's gonna be originally uniform. We simply re-sample this point. Then this is a completely uniform stuff then we can have the probability here and because of the re-sampling lemma these two probability doesn't really differ much. We can establish original bound of our original evaluation. So our final construction, oh, there's a second challenge, second challenge we want to get a programmability or the other nice stuff. So in order to have full simulation actually we just add one more layer of hash at all the constructions. Okay, I already almost explained how we tackle the two challenges. The first one is after we draw all the post, expose all the random values and we just pick up the good term and re-sample this one, pretend we never see it because after re-sampling is a uniform thing and the whole string gonna be essentially uniform. And after the re-sampling will get the bound we can essentially prove that the internal terms is kind of completely out of control of the adversary and it will be unpredictable to the adversary if he never really evaluate at all these points. Then applying one extra layer, sorry. Then applying one extra layer we can easily imagine the whole thing gonna be uniform again. And also of course we need to handle all the conditions all based on different adaptive queries but all these conditions can be handled in a similar way of the following the same structure. So now we, after we're seeing this construction we show you the proof that if we just mixing and shifting the hash function enough times we indeed get a corrected version of run oracle. What does that mean? That means we can safely deploy the hash implementation in real life as long as we wrap it according to our correction. So the early threat I mentioned in the attack now we can be prevented. We can safely deploy a new chain while still using the hash implementation. Say we have the hash implementation in the mining machine then the genesis block gonna be chosen and the public randomness gonna be put in the genesis block. Then the miners are then the miners essentially gonna use the wrapped hash function to safely doing solving their puzzle solutions and confidently deploy the new chain. And many more immediate applications when we replace malicious implementation. And I would like to end the talk with a very simple reflection. So it seems a lot similar to a classical result called self-correcting programs. Well, there takes a 40 program, try to correct it that is arrow at the small fraction of input we won't turn it to be correct with almost correct at every input. Well, here we also have a hash function which is gonna be incorrect at a small portion of input. But there are subtle differences. First in self-correcting programs we are allowed to use private randomness but on the other hand we need to preserve the exact functionality. If we compute x plus two we still need to compute x plus two. But in our setting we don't have the luxury of a public randomness to use as we explained because RANORCO is a public object. But on the other hand we don't really need to preserve the exact functionality. A SHA-256 after wrapping might not even be SHA-256 but we preserve all the distribution properties. In some sense we can view our result is kind of distributional version of the classical theory. And I hope this perspective might give some more inspiration that we may consider developer a different path of the classical theory. And there are many open problems left. For example, we may optimize the analysis a little bit to get better parameters, get better constructions and or maybe we don't really need to save all the properties of the RANORCO. We also list to simpler construction. There are many more. Thanks.