 Hello, my name is George Lu and this talk will be about new techniques in replica encodings and client setup So replica encodings are this primitive that were introduced in a paper last year by Damgard Ganesh and Orlandy and the Ideas you have a client with the message and he wants to produce several replicas of this message Where each from each replica independently you should be able to recover the original message But you have say you have an adversary that takes a look at all of these replicas He should not be able to compress them and store them in states significantly smaller than the size of the original replicas And this has some uses and the decentralized file storage More formally we can define a replica encoding scheme as a set of three algorithms There is a setup algorithm, which takes in your security parameter along with and and an a priori found on the number of replicas this Parameter set is able to produce and outputs a public key and a secret key There's an encode algorithm which takes in a message and produces an encoding and Corresponding decode algorithm which goes from an encoding back to the message itself Now there are a couple properties we want of such a replica encoding scheme Perhaps most obviously we would like it to be correct. So if you Run a message through encode and then run it through decode, you know, hopefully you would end up with the same message again We'd also like for the there to be some efficiency properties Where the replica shouldn't be too much larger than the original message itself in the case of the schemes that we look at This ends up being only an O of security parameter additive factor larger than the original message Finally to capture the Incompressibility property that we want that and we discussed earlier There's we define this soundness game where a challenger takes a message Runs encode to produce several replicas of the message And gives it to an adversary and this adversary takes a look at these replicas and Outputs a state file which can be anything it wants to a second adversary and the second adversary Only has access to the state file along with the original message and its goal is to produce Reproduce as many of the original replicas as possible So to judge the success of an adversary in this game We compare the size of the state file and produce with the size of the replicas. It was able to successfully reproduce And we say we say a scheme is s sound if we're all poly time adversaries the ratio of this Of this storage use with the replicas it was able to reproduce is Almost always a larger than us And ideally we want this asset s factor to be as close to one as possible So in the dgo construct 19 construction, they use a couple of ingredients They use capital permutations Random oracles as well as invertible random oracles, which are just random or random oracles to permutations Which also had a publicly computable inverse So how the construction actually goes is that well, there's a message m we break it up into B blocks of length capital And for each individual block We start by XORing it with the random oracle output of this random string row concatenated with the block index i and then We take this whole thing We run it through the invertible random oracle Then we run it through the copper permutation inverse And then we do run it through the random Invertible random oracle again and so on and we keep on doing this until we are until we're I guess essentially satisfied after our rounds and At that point the actual encoding is just going to be yr for all of the individual blocks along with the row Random string from earlier So we can see that this is At the very least correct in that we should we can recover the message from the encoding by Just using the tropical permutation public key Since to work We to work our way from yr to y0 We just need to evaluate the tropical permutation in the forward direction Along with the inverse of the invertible random oracle which is also public But we could hope that this is secure Because we'll take the because going the other way would require directly at least requires using the secret key So for the adversary, which doesn't have the secret key We'd hope that they need to commit a lot of space to remembering these tropical permutation inverses And so In the work last year, they They show that for rounds equal to omega of capital times n This is a pure replicating coding scheme for any constant s less than one And what our first contribution is it's actually a lower bound on the efficiency of this This construction Where we show that for rounds in little o of b times n This construct this construction is not an s sound replicating coding scheme Uh, but if you look closely at these two theorems, you can see that they're actually Uh, kind of contradictory in that For our lower bound, we we claim that the number of rounds needs to scale with the number of blocks Uh b But this this factor is not present in the actual construction of replicating codings in the original theorem So let's take a let's take a closer look at these two results That's we can start with our lower bound results and the way we show Our lower bound is by constructing a specific trapper permutation And along with an adversary that has an attack strategy on the replica encoding schemes When the when instantiated with this trapper permutation and so How we do this is in addition We take any trapper permutation and in addition to the public key and secret key We also we also attack a public obfuscated program to the trapper permutation where Which assists the adversary in inverting inverting it Now to ensure that this is still a secure trapper permutation. We also require that they That when in order to use this obfuscated program You need to certify that you've already that you already know the in some sense know the outputs that you're trying to request So in particular we require that they give the XOR of all the random oracle outputs. It's trying to compute So the actual paper this is slightly more complicated and uses indistinguishability obfuscation To show security But for the sake of this talk We'll assume we have this sort of heuristically obfuscated program here And of course the idea here for the attack being that You only Need to store this small XOR in the state in order to get all of these trapper permutation inverses Now concretely for the adversary of the scheme What it'll put in its state is the random string row As well as the what the XORs of these y of the y Blocks for every where will it also are one of these for every single round that the construction has to go through As a reminder on the right, this is what the actual replica encoding is and what then this is what the adversary will try to reproduce So we can simply run through the steps of the construction and see that the adversary Using the state and compute all of these steps So to start off you we take m we split it into these blocks Because it has row it can compute the XOR with the random oracle with no issue To get the y zero blocks And now to go from the y's to these this just requires an evaluation of the invertible random oracle, which is public There's no problem for the adversary And now to go from the z's to the y's. This is normally where you use the trapper permutation inverse But all that all that the adversary needs to do is just take one of these Blocks one of these quantities that it's remembered in state To just like that invert all of these blocks and get its y i's And the important thing to note here is that this XOR quantity doesn't scale with the number of replicas Sorry, it doesn't scale with the number of blocks in each replica But of course the size of the replica itself does scale with the number of blocks it contains So in order to make sure in order for an adversary to still be as spatially Inefficient in order to make it Unsound in the soundless game you would need The only way to make this adversary in particular unsound is to increase the number of these XORs which it has to Store and these XORs only scale with the number of rounds in this game. So that's Oh, that's how we get our lower bound and so if we go back to the DGO theorem this actually I think highlights an oversight in their analysis, which was that they implicitly assume that The storage of the adversary and sort of the bits of the storage of the adversary can sort of be attributed to individual random oracle queries, which it's made um And that between different random oracle queries these sort of accumulate additively um but from the From our previous construction we can see that this is not always the case Uh, so just taking taking our first result. This leaves open a pretty I would say important open question, which is can replicating coatings actually be constructed? uh, unfortunately Uh, we also show that just by reparameterizing the scheme to include this to include this b factor this This is this same construction is still a secure replicating coating scheme Uh, I'd also like to mention that there was some concurrent work by moran and wix, which also Notice the same issue That the original DGO construction has but they they constructed replica encodings, which they call Uh incompressible encodings From entirely new they they propose an entirely new construction of this from different assumptions using different techniques uh, and so But uh back to our result so Since the prior work, you know heavily relied on this implicit assumption that the entropy of queries sort of Was separated we needed to We needed to implement a new proof strategy to show the security of our reparameterized scheme So our security proof roughly breaks down into two main components which we call sequentiality and switching So for the first step of sequentiality What what we click what we show is that That there's some block in which any adversary information theoretically has to query In in sequence where they have to query y zero first before they query The random oracle on y1 before they query on y2 and so on all the way to yr And now once we've shown this We can argue the next step which is that Uh given the limited amount of space which the adversary has If an adversary is successful in the on the normal encoding There's also must be some location on this uh sequential path Which if you replace the i plus one with a random With sort of a random element then this on this other like alternate encoding the adversary should still be successful And using and once we arrive at this point, uh we can sort of We're able to take this adversary And if it's able to if it's able to succeed on this in this random version Then it should also just by Just by inspecting the random oracle queries, which it makes we should also be able to just invert the trapper permutation Which of course should not be possible Uh for the sake of this talk, we'll focus primarily on this first step of sequentiality and how to show this um Yeah, so this is done through what through a fairly simple observation which is So supposedly have a random permutation here Uh where we've highlighted the We've highlighted the matching pairs with the same color And if you're only if you can only make a few few queries to this, uh random permutation Then the probability that you output a pair that you haven't queried is actually very low um in particular for the Problem that we care about we say that okay if the domain is of size two to the kappa And you can only query this random permutation in polynomially many spots then The probability that you output this matching pair That you output any matching pair in fact is going to be negligible in kappa times two to the negative c times kappa for any c less than one And so another way to interpret this actually is that even if you're given c times kappa's State we can treat each of the possible state configurations as its own adversary and sort of and just union bound the Probability that any such adversary succeeds with negligible probability And In the actual okay in the actual proof this also scales up to outputting multiple pairs so Correspondingly say if you want to output three matching pairs Then even if you had three times c times kappa state It should you should this adversary should still only have negligible probability in dune so How does this correspond to the original notion of sequentiality? Well, if you imagine that at some point you have an adversary which is non sequential And go like they queries y zero and then queries y two without querying y one then We can reduce this to the matching pairs game before by By after they query y two we can compute We can compute z one from y two and we compute Why we can compute y one from y zero and now we have this y one z one pair Which is a matching pair of the random oracle who we've never queried their random oracle on y one itself and so That's how you show sequentiality And for and finally we have the third result Which is that using sort of the same techniques We can construct the a replica encoding schemes in the random oracle model using by replacing the Invertible random oracle with a feistel network structure And it turns out that using a very similar Using a very similar sequentiality and switching framework with a bit more casework involved We can show this the security of this construction as well Thank you