 Thank you very much for the introduction. It's my great pleasure to be here today and present to you my joint work with Benny Ili and Pratjaye About continuous space-bound at non-mobile codes. Okay, so let me begin with the short motivation Imagine that you have a small memory device that performs some cryptographic functionality So that means that some secret key is stored in the memory of this device So on this example, you can see digital signatures and the security property of digital signatures Guarantee that no one can forge a signature Okay, but what happens if now an adversary can temper with the memory of this device So it changes the secret key to some tempered secret key prime. It turns out that in this case some information about the secret key can be leaked and Even enough information to recover this entire secret key. So the unfortunate ability would be completely broken in this case So what can we do about it? And we are in the session of non-mobile code So we're gonna one way how to protect against memory tempering is using a non-mobile code for this example for space-bound at Tempering so roughly what would happen here instead of storing the secret key on the memory of the device We would store an encoding of this secret key And as you had heard from the previous speakers The property the non-malleability property would guarantee that even if someone tempers now with the memory No information is leaked about the original secret Okay, so a space-bound at tempering was first time considered in a paper that was presented here in at crypto two years ago And what what is actually space-bound at temporary? We restrict the tempering function just by the resources of the device more specifically We say that the space complexity of the tempering function and the space complexity of the decoding algorithm are bounded by the memory of the device and This actually implies that the tempering function can decode And it's not so difficult to see that in this case full non-malleability is actually impossible to achieve So to this end a definition of a leaky non-malleability was introduced Where it's allowed for the tempering to leak some small part of the input just a small part and for many applications This is completely fine. For example for leaky resilient signatures Okay, so the prior work introduced a generic construction Generic space-bound at non-mobile code and it was based on non interactive proof of space. That was the main building block However, it had one limitation Namely that the size of leakage was growing linearly in the number of tempering rounds and This implies the tempering is a priori bounded. Why is this? Well We leak every time for every tempering round. We have some leakage. So eventually we would leak the entire secret key So the protection given by the non-mobile code would be completely meaningless and What was less as an open question is to achieve an unbounded polynomial unbounded tempering and This is exactly what we focused on in our paper and what I will be talking about today Okay, so our goal is to have a space-bound at non mobile code for unbounded tempering and we actually looked at the generic code construction from the prior work and We kept the construction as it was but we instantiated it with a stronger building block in particular, we defined something we call proof extractability of proof of space and We show two different approaches how to construct such a proof of space and we end up with several Construction that have different parameters, but I will tell you more about that in my talk Okay, so before I get to the code construction Let me be a little bit more precise about what leaky non-mobile codes are. It's not a formal definition, but just to give a high-level idea Okay, so we have a coding scheme that consists of encoding and decoding algorithm and consider a polynomial time Algorithm polynomial time adversary that is space unbounded. Okay, so we have no restrictions on space and It can prepare a tempering function that can be arbitrary but space bounded and this tempering function now Tempers with a target code word C and tempers to a code word C1 The adversary then learns the result of decoding of C1 And we say that our coding scheme is L leaky non-mobile if there exists a simulator that can simulate this tempering experiment Without knowing the original secret but getting a small hint Okay, so it can get L bits of leakage and then has to simulate the tempering experiment This definition can be Generalized for repeated tempering so after the first round of tempering as you saw on the previous slide Adversary is allowed to pick another tempering function Which now tempers with this C1 to C2 and again adversary learns the result of decoding of C2 Okay, so now we are prepared to have a look at the non-mobile code construction so as I said before it's based on non interactive proof of space so non interactive proof of space is a Primitive between two parties So we have a prover and a verifier and prover has a lot of memory and it wants to convince a space bounded verifier about this fact So what he do what he does he takes some unique identity It generates a proof and this generation requires a lot of space and Sends over the identity and the proof to a verifier and the verifier is able to verify that This is a valid pair So that was just on very high level and the code construction is now very simple if we want to encode a message M We just run The proof algorithm of the proof of space we generate a proof and our code word consists of the message in plain And the proof attached to it The decoding while we first parse the code word into a message in the proof We run the verification algorithm, which does not require a lot of space Right, that's the property that we get from the proof of space and if everything is fine We out put a message M. Otherwise we get an invalid code word Okay, so before I show you why this is a leaky and non-mobile code and why we actually have bounded Tempering in this case We need to have a little bit closer look at the building block at the non interactive proof of space or nipples for short In particular, let's have a look at the soundness property or the the property that guarantees that Prover cannot cheat. So if the prover does not have enough space, he should not be able to convince the verify, right? So how do we formalize this? It's an experiment or a game and we again have a polynomial time space unbounded Adversary that can run some arbitrary pre computation. So for example prepare some identity proof pairs and The adversary now prepares a space bounded temporary function that tempers with the target identity and a proof and Now if the result of temporary is actually a valid pair Then the extractability tells us that this ID till dies either the original identity or One of the pre computed values in which case we are able to extract From the pre computation this ID tilde. So given a short hint. We are able to extract ID tilde or Set differently space bounded algorithm cannot generate a valid proof for a new ID Okay, so let's have a look at the code construction. Why it's actually leaking on mobile So just a sketch of how a simulator works. There are many technical details missing But just to give a high-level idea. So the simulator gets the first tempering function And it asks a leakage oracle for a short hint and by extractability given this short hint It's able to extract the identity so it's able to extract this SK one and Now for the next round of tempering Well, it does exactly the same it again asks for a hint the leakage oracle Simulates the tempering depending on the result returns back a hint We extract SK to and so on and so forth So as you can see for every tempering round Every tempering we need one leakage query and this is exactly why We don't achieve unbounded temporary. So this is the problem in the prior work So can we do better and the answer is yes, and it lies in stronger proof of space So what do I mean by that? In particular in our paper we define a notion of proof extractability and as the name suggests We don't want to extract only the identity but also a proof Okay, and that's exactly what's happening here instead of extracting only identity ID tilde We also want pi tilde or if you look at it differently We want to say that a space bound that algorithm algorithm cannot generate a new valid proof Not even for old IDs. Okay So the culture instruction is exactly the same as in the prior work But we have proof extractable non interactive proof of space and This helps and this helps and let me Show you how so the first round of tempering the simulator gets the tempering algorithm Again, asks the leakage oracle to simulate the tempering experiment inside and return back a hint given this hint We are able to extract Identity and a proof which means we have the entire code word C1 So fine the first round we managed to simulate But that was the same is in the prior work as well But now comes the difference when we get the second tempering algorithm Now we don't have to ask a leakage query anymore. We have the C1 We can just simulate the tempering experiment without further leakage and that's exactly what we wanted So as you can see the number of leakage queries is now independent of the number of tempering rounds Okay, so the big question here is now. Okay, how can we how can we construct proof extractable nipples? And in our paper, we consider two different approaches and I will tell you a little bit about each of them I can unfortunately not go in detail, but just to give you an idea So let me start with the uniqueness approach So we say that nipples satisfies you uniqueness if a valid proof like if the identity Identity defines uniquely you bits of a valid proof Okay, so you bits are uniquely defined and the n minus you the remaining bits. We don't know and It's not so difficult to see that extractability and uniqueness Together actually imply proof extractability So what's the main idea behind it? So if the result of tempering this id tilde pi tilde is actually a valid pair Then by extractability, we are able to extract this id tilde So id tilde we have so now the question is how do we get pi tilde? by Uniqueness or you uniqueness we know the you bits of the proof So but we still don't know n minus you bits So in other words if we get as a hint the hint that we need for extract ability plus the unknown bits We are able to extract entire identity and approve So obviously our goal here is to come up with the non-interactive proof of space This that satisfies as high uniqueness as possible Okay, fully uniqueness would be ideal, but we want to achieve as high as possible So first of all we looked at the prior work and saw that the non-interactive proof of space had zero uniqueness So technically yes, we do get approved extractable nipples, but with very bad parameters So we also considered a heuristic construction based on memory hard functions So let me give an a rough idea how our proof algorithm actually works So on input the identity we first hash this identity and then evaluate a memory hard function That's a function that requires a lot of space to compute So this would be fine. We have memory hardness So it's the prover has to use a lot of space, but we don't have the efficient verification So to this end we actually run a verifiable computation to produce a very short proof that the computation was done correctly So that's the high-level idea. We get a partially unique nipples The details I refer to the paper But I want to point out. Why did I say heuristic? Where is the problem here with this construction? And it lies in the memory hard function because we have memory hard functions in the random oracle model or in other idealized models But in order to run verifiable computation, we would need to instantiate the random oracle with a concrete hash function So that's why this construction is just a heuristic Okay, so let's have a look at the other approach how to construct proof extractable non-interactive proof of space in particular from challenge hard graphs that we introduce in our paper So here I have to also give a small warning We have to slightly weaken our adversarial model But in a realistic way and I will show you in few slides what this means or what I mean by this So first of all in order to explain challenge hard graphs Let's consider a direct acyclic graph. Okay, so we have a directed acyclic graph and We have a hash function h. So if we want to compute a h labeling of such a graph We want to assign a label to each node and we do it as you can see on the picture For example, this black node if you want to compute the label where we look at the labels of all their children of this node And we hash it together Okay, so now we are prepared to actually explain what a challenge hard graphs are So we consider a directed acyclic graph and we divide the sinks of this graph in several sets We call them target sets. So in the picture, they're just two but We randomly select one challenge node from each target set And we say that a space bounded algorithm can label all the challenged nodes or all the challenge nodes Only with negligible probability. Okay, so space bounded algorithm. It's very hard to actually label all the challenge nodes and This should hold even if some of the labels are given for free To the space bounded algorithm not all but some Okay, so how does this help us to get proof extractability? High-level overview of the construction details are again committed. So We have a hash function h that depends on the input identity and we first of all compute a Labeling of our challenge hard graph then we use a Morocco tree to commit to this labeling and We hash the route to generate RAM known as and define two sets of nodes First set is so-called check notes and the purpose of these check notes is to verify that actually their labeling was done correctly So we open We provide the opening path for this node and its children and we check that the local correctness of the labeling The second set is the challenge node So one node from each target set and this is for the for guaranteeing that it was memory hard or it was space Exhausting to do this computation So why is this proof extractable just the main idea? Well, either the adversary pre-computed the entire labeling and the mocha tree so everything was pre-computed and in this case we are able to extract id tilde and pi tilde from the pre-computation or The adversary did not do everything in particular He did not compute the root and did not have to root so he did not know the challenge nodes and In this case we use the challenge hardness to say that the Tempering algorithm has a negligible success probability to answer all the challenges correctly Okay, and here it's actually important that the Tempering algorithm has a bounded description and If we go back to the application that I showed you at the very beginning Assuming that the description of this tempering function can be absolutely arbitrary Might seem to be a bit of an overkill So requiring that the description of the algorithm is bounded is not such an unrealistic assumption Okay, so what remains to discuss is how do we get challenge hard graphs? What are they? How do we get them? So first of all we looked at stack of localized expander graphs from Ren and Devadas from 2016 and We extended the construction to achieve nice parameters for challenge hard graphs So high-level idea of the construction We group the sinks of the solec of the stack of localized Expander graph and we put a gadget graph on top of each group You can see on the picture how each gadget Graph looks it has several lines and how do we now connect this gadget graph to our sinks Well, we take the first sink and connect it to the first node in each line We take the second sink and connect it to the second node in each line and so on and so forth, okay so We also evaluated Graph construction given by Paul and then later used by Jamboski et al in their proof-of-space construction And actually it shows that they also satisfy challenge hardness In fact with better asymptotic parameters than the extension of solecs However, the constants are large. So if we evaluate for concrete security The extension of solecs performs way better Okay, so we have we I discussed now four different constructions for proof extractable non interactive proof-of-space which gives us four different constructions for our non-mobile code So let me conclude my talk with a small overview So what we wanted to do was generic space-bounded non-mobile code construction for unbounded tempering and what we did we took the construction from prior work, but instantiated it with proof extractable non interactive proof-of-space and As you saw on the previous slide there were four different construction with different Adventures and disadvantages here you can see an overview in the paper you can see both asymptotic and concrete parameters and a more detailed overview here is just to give you an idea How practical or impractical? Constructions are so if you look at the first line the pri which represents the prior work We are in order of terabytes It's not very practical On the other hand if you look at our memory hard function based construction We are in order of kilobytes. So so the gap is huge and somewhere in between We have the challenge hard graph constructions and here you can also see that the solec based one out performs the original construction from the proof-of-space paper Okay, and what we leave as an open question for for or as a future work To design a fully unique non interactive proof-of-space because that would lead to and memory To a non-mobile code with very nice parameters Okay, so that's everything. Thank you very much for your attention and I'm happy to answer any questions questions Hello In continuous non-mobile codes usually there is this problem of self-destruct Yes, meaning that as soon as you get an error you should stop but it seemed that you never mention it Yeah, I did not mention it, but yes We do need self-destructive that you need that essentially always for continuous Yes, we do need self-destruct when you say the boundary you bound the size of the Adversary what what is this like by a constant? No, I mean I mean all the parameters depending on each other So it's a parameter and of course you have to a link to the remain Well, it depends on the soul it depends on concrete like which of the constructions you take Okay, so we can talk about details later offline. Okay. Thank you again