 Hello. All right. Thanks for the introduction. So today, I will be talking about explicit rate 1 non-medical code for local tempering. So this is joint work with Stevia Gupta and Hamata Maji. So let me first tell you what is non-medical code. So you have already seen some of this from Marshall's talk, but let me just quickly remind you. So non-medical code is a primitive introduced by Zimbofsky, PyTrak, and Witz back in 2010. So this primitive is originally motivated by temper resilient cryptography. So imagine you have signature schemes where the adversary might be able to temper the internal state of the challenger and then obtain a signature under some tempered secret key and then try to forge the signature under the original secret key. Under such tempering attacks, the classical security guarantee of the signature schemes does not say anything about whether the adversary could succeed or not. So the idea is that if we use non-medical code to encode the secret key, this could help preserve the security of the signature schemes, even in the presence of such tempering attacks. So intuitively, non-medical code is a coding scheme such that if some tempering happened on the code word, then the tempered code word either encodes the original message or some message that is completely unrelated with the original message. Specifically, let's say you have a message that is first being encoded and then tempered by some function F and then you get the tempered code word and then you decode this tempered code word to get the tempered message. So we want to say that this tempered message, message tilde could only be related with the original message in three following ways. The first way is by identity function, meaning that the tempered message is identical to the original message. The second way is a special symbol, but simply means that the tempered code word is an invalid encoding. And finally, the third way is a constant function, meaning that this tempered message is being fixed to some constant no matter what the original message is. More formally, non-manable code ensures that for this tempering function F, we can, there exists a simulator that outputs a distribution over these three types of functions such that the distribution of the tempered message in the real word is indistinguishable from this simulated distribution. So note that this simulator only takes the tempering function as the input and is oblivious to the original message. So if you think about this definition for a while, you will quickly realize that this tempering function cannot be an arbitrary function. The reason is very simple. So since this is a coding scheme, the tempering function can always first decode the code word first and then flip a bit of the message and then re-encode. In this way, the tempered message, message tilde will always be the original message with one bit flipped. Then there cannot be any simulator that simulates this process. Therefore, non-manable code is always defined with respect to a fixed set of tempering functions. And just like error correcting codes, we define the rate as the ratio between the length of the message and the length of the code word. So intuitively, high rate here implies that the overhead of achieving non-manability is low. So since the introduction of non-manable codes, after many years of research, we find that non-manable code is actually closely related with many other primitives in crypto. For example, in the field of privacy amplification, we have this primitive called non-manable extractors and it turns out that non-manable extractors and non-manable codes are very closely related. And we have many excellent research going on in this area. Next, in the setting of multi-party computation, we also have found constructions of non-manable commitments using non-manable codes as building blocks. In relatively new primitives, called non-manable secret sharing, many of those constructions of non-manable secret sharing also use non-manable code as a building block. So the research objective of this line of research is to find explicit construction of non-manable codes with high rate against sophisticated tempering families. So high rate directly translate into high efficiency in those applications and reductions. And the sophistication of such tempering families implies a stronger security guarantee. So in this talk, we will be focusing on local tempering. So let me first tell you what is local tempering using a very simple example. So here, we have a code word that consists of four bits, a one, two, three, four. So this tempering function will take these four bits as input and output a tempered code word. So here, the first input bit will depend on, the first output bits will only depend on the first input bit and the second input bit. And the second output bit will depend on the first input bit and the third input bit, and so on. So we say a tempering function F has delta output locality if every output bits depends on at most delta input bits. So here in this example here, every output bits depends on precisely two input bits. So F has two output locality. Analogously, we say that F has delta input locality if every input bits influence on at most delta output bits. So in this example here, the first bit actually influence on all the output bits. Therefore, this function F has four input locality. So we say a tempering function F is delta local if it has delta output locality. So do note that for delta local tempering functions, this function can actually have arbitrarily large input locality, just like this example here. And this fact actually turns out to present significant technical challenges when designing non-mailable code. So in this work, we gave a compiler that compiles a low rate non-mailable code into a rate one non-mailable code. So specifically, for any constant C between zero and one, we gave a compiler that compiles a low rate non-mailable code against local tempering with an appropriate leakage resilience property into a rate one non-mailable code against this constant C times log n local tempering. So ball at all gives the first feasibility result of non-mailable code against the local tempering. Our compiler instantiated with ball at all construction gives us a rate one non-mailable code against C times log n local tempering. And as a corollary of our results, we obtain a rate one non-mailable code against NC0 tempering. This is because NC0 tempering is all the tempering with constant locality. So to give you a more detailed comparison, when the locality is a constant or NC0 tempering, ball at all construction has a rate, has constant rate while our work has rate one. When the locality goes beyond constant and is smaller than the threshold we set here, our ball at all construction has a decaying rate while our work still has rate one. When the locality goes beyond the log n, ball at all construction, the rate of their construction is linearly dependent on the inverse of the locality. Unfortunately, our work does not extend to this case. So as a very cool application of non-mailable code against local tempering, ball at all construct non-mailable code against AC0 tempering. So in this application here, they actually requires the building block, the non-mailable code against local tempering to have a very high locality. So our work here does not improve the rate of their AC tempering here. So before I go into our compiler, let me tell you a bit more about what do we know about non-mailable code against local tempering. So we have very nice Monte Carlo constructions that tells us when does rate one non-mailable code exist based on how large the tempering family is. Such Monte Carlo constructions implies construction in the common reference ring model. So firstly, fourth at all tells us that when the tempering family has size two to the polyn, rate one non-mailable code exists. And the more over, their construction is efficient. When the tempering family size goes beyond that and it's actually two to the small of n, Chilachi and Gruswamy's results tells us that even in this case, rate one non-mailable code still exists. However, their construction is inefficient. So a quick calculation will show you that for a delta local tempering family, the size of this family is roughly two to the two to the delta times n. So if you plug in delta with order of log n, fourth at all results tells us that efficient rate one non-mailable code exist in this case. When delta goes beyond log n and is still small of n, Chilachi and Gruswamy tells us that rate one non-mailable code exist. However, it remains unclear if efficient rate one non-mailable code exist in this case. So as a reminder, our work here shows that we can get explicit efficient rate one non-mailable code when delta is smaller than some constant times log n. So before our work in a plain model, all the known explicit rate one constructions are actually against functions that has input locality one and output locality one. Such tempering families is referred to as speed level tempering in the literature. So now let me tell you about our compiler. So fix any constant c between zero and one, our compiler will use the following ingredients with appropriate parameters. First, we will be using error correcting secret sharing schemes that has rate one and the near linear distance and also near linear independence. Such error correcting secret sharing schemes could be based on standard read Solomon code. Secondly, we will be using a base non-mailable code that is secure against order of log n local tempering. So this base non-mailable code could possibly have very low rate and in addition to non-mailability, we require it to be resilient to a constant fraction of leakage. Finally, we will also be using a pseudo random generator against a finite stain machine by Nissan. So we remark that other alternative pseudo random objects potentially also suffice here. So given these three ingredients, our error correcting secret sharing schemes, a base non-mailable code and a suitable pseudo random objects, our compiler will use these three ingredients in a black box way to output a rate one non-mailable code against the c times log n local tempering families. So our construction draws inspiration from the following two components. The first is a rate amplification techniques by Agarwa at all. And second is a PRG techniques by Boyd all. So let me tell you a bit about both of them. So Agarwa at all constructed a rate one non-mailable code against a bit level tempering. So here is just a very simple example of what a bit level tempering looks like. So such functions has input locality one and output locality one. So their compiler is constructed in the following way. So given any message, the first they first encoded this message using error correcting secret sharing schemes to obtain a code word A. Next, they will sample a subset of those indices from code word A. And for roughly half of those indices, they intentionally introduce errors into this code word. And for the other, roughly other half of those indices, they will keep those bits untouched. Next, they were encoded this consistency check information using a base non-mailable code. So their final code word consists of two parts. The main code word C, the main code word C, which is error correcting code with arrow introduced, and then a tag which contains, excuse me, contains the consistent check information. So to decode this code word, one first decode the erroneous error correcting code and then cross check the information of those errors with the tag to see if they are consistent. So unfortunately, their techniques here does not extend to tampering functions with high input locality. Actually their compiler does not even extend to functions with input locality too. So in order to deal with this technical challenge, we use the PRG technique by Boydor to circumvent the technical challenges posed by input bits with high input locality. So on a very, very high level, imagine you have a code word that has two parts, the left part and right part. So these techniques will keep the left part as it is and then hide the right part among many, many redundant bits. And the position of those informative bits from the right part is hide among the string pseudo-randomly. So using this, one can argue that it is very unlikely that an informative bits from the string actually have a high input locality. So this property turns out to be very useful for our proof. So given, so our compiler first follows the framework by Agawa at all. We also encoded the message using an error correcting code and then introduced some errors and also keep some bits untouched and record this information using a base non-manable code. And after that, we will be using a PRG to hide this tag among a list of strings that contain both the redundant bits and the informative bits from the tag. So our final code word consists of three parts. The main code word, which is an error correcting code with errors introduced, then a seed for the PRG and then this string here that contains both redundant bits and informative bits from tag. So the length of this code word is roughly same as the length of the main code word. So let me give you a very brief sketch of our proof. So our proof roughly falls from the following way. So we first argue that the tampering happens on the tag is actually independent of the message here. Then given this observation, we can say that the tampering on the tag either keeps the consistent check information identical or fix this consistent check information to a constant. So this is given by the property of the base non-manable code. So finally, our intuition is that if the adversary keeps this tag identical, then the only valid tampering is to also keep the main code word identical. Conversely, if the adversary fixed the tags to be some constant string, then the only valid tampering is to also fix the main code word to some constant. So the idea is that if the adversary does not tamper this code word in this way, then with probability one minus negligible, he will always fail the consistency check. So the hardness of this proof completely lies in how do we prove this intuition? So unfortunately, I don't have time to go into the details of this proof. I would be happy to discuss this offline and I will end my talk here. Thank you. Questions? Yeah, you said that there was a previous result that supported log locality. I think one of the authors was Faust and it was efficient. So can you explain again what is the difference? So they show that it's a probabilistic construction. They show that actually with probability one, their probabilistic construction will be secure against that tampering family. However, we cannot de-randomize such Monte Carlo construct. So it's not an explicit construction? No, it's not explicit. More questions? Let's thank the speaker again.