 Thank you so much. So I'll talk about proofs of replicated storage without timing assumptions, and this is joint work with Yvonne Damgard and Claudio Orlandi. So let's begin with the motivating example. So we have a client here who would like to outsource the storage of a file to a server, and for reasons of availability, would like to store different copies of the file in multiple locations, so that if at some point some servers crash and some copies are unavailable, the client can still retrieve the original file. The problem, however, is that if the servers are corrupt and collude to save costs of space, they can actually only store one copy of the file. So what we need is a way for the client to make sure that there is indeed replicated storage and unique spaces dedicated to store each copy of the file. So this notion of proof of replicated storage is related to some classical notions of proof of storage, and also to a notion of proof of replication that is introduced by the cryptocurrency Filecoin, which gives a method to give a useful proof of space, and I'll say a little bit about why these notions don't solve our problem and how they are different. So Bitcoin uses a proof of work as a method to deal with civil identities, and this is known to be largely wasteful, and the question is, can we instead use a proof of useful resource in place of work? And Filecoin proposes to use storage as this resource, which would allow one to have a distributed storage network where miners dedicate storage to store useful files instead of dedicating work. And this gives a useful proof of space, and I'll say a little bit about why that doesn't solve our problem later, but classical notions of proof of storage are not already proofs of replicated storage for the following reason. So proof of retrievability is a solution to the following problem. So we have a client who would like to outsource the storage of a file to the server, so there is a store algorithm that takes the file F to be stored, returns a Y that is shipped off to the server, and some verification information T that is stored at the client side. And then there is an audit algorithm where the server can actually convince the verifier that it is still storing all of the client's data, and at the end of the audit protocol, the client outputs a bit indicating whether it believes that the server is storing the file or not. Now the notion of security here in proof of retrievability is that of soundness, which essentially says that if the client accepts here in this audit protocol, then there exists an algorithm called the extractor that can actually interact with the server and extract this file. But this notion only shows that the file is stored once and gives no guarantee when there are multiple servers. In particular, if we go back to our original problem and say the client insists that the servers give a proof of storage of F, this still does not solve the replicated storage problem because even if the servers give valid proofs such that the client accepts many different proofs, it could be because the client is simply talking to one adversary, and there is really only one copy of the file still stored. So to be able to talk about proof of replication, we really need different encodings of the file. And one idea that comes to mind is to simply use encryption. So maybe the client can simply have each encoding be a ciphertext of the file to be stored using fresh randomness for every replica. Now as far as the adversary is concerned, each encoding is indeed a different file, and for it to be retrievable later, the server indeed has to store all the ciphertexts. So this does solve the problem, but the issue is that this requires the client to store a secret state, which is the encryption key. And additionally, this is not publicly verifiable. So ideally what we want is not just the client, but everybody else to be able to retrieve the file later. And if we simply use an encryption scheme, the client will have to share the encryption key with other users, and now if one of these users is valued with the server, we don't have security anymore. Another notion of encoding used in this context is that of slow encodings, where the encoding is so slow that a client can distinguish between honest proving time and potentially adversarial proving time that includes the time to re-encode. This looks like the following. So the client computes an encoding of the file to be stored using a slow encoding method, a sense of the encoded file to the server. And now if the server does not store the file, but later actually gives the proof or is retrievable later, then this means that the server had to re-encode, re-compute this encoding. And because this is a slow encoding, the client can detect that this is taking a long time for the response in the challenge response protocol and time out and not accept the proof. So the setup is the following in slow encodings. The client computes a bunch of encodings or replicas, sends it off to the server, and then there is a challenge response protocol. And now there is a notion of time here. And if the response comes within a certain time out, the client accepts the proof as being valid, otherwise it is not. So if the server is actually trying to re-encode, then it incurs a detectably long delay and the client can simply time out. So the problem here with the slow encodings is that they rely on timing assumptions, which means that we have to estimate the time that a very powerful server could take so that it doesn't fool the client into accepting a proof even when it is re-computing the encoding. And this results in difficulty in setting concrete parameters like when should the client actually time out. And the notion that is introduced by Filecoin and all subsequent works actually are time bounded proofs and rely on timing assumptions. So the question we ask here is, can we have a proof of replicated storage that does not rely on timing assumptions? So in this work we introduce a notion of replica encoding and use this notion to give a definition of proof of replication that does not rely on timing assumptions and then give a construction that allows for public verifiability without timing assumption. So I'll begin with our notion of replica encoding scheme. So we have a replica encoding algorithm that takes a file and some randomness and outputs a replica. And there is a decoding algorithm that takes the encoded replica and returns the original file and completeness simply says that decoding should actually retrieve the correct file and the notion of soundness is the following. So to be able to meaningfully talk about space we think of a two-stage adversary A1 and A2. So here the adversary A1 outputs a file to be encoded. The client computes many different replicas, YIs, and gives it to the adversary. And the adversary outputs a certain state. And now the second stage adversary A2 takes the state as input and outputs some perverted encodings, Y-primes. We say that this adversary, this two-stage adversary wins the soundness game if the following holds. If the state is too small, but the number of encodings that A2 returned using only state that was given by A1 did not actually fit in the state. So what this definition says here is, let's say U is the number of encodings that A2 correctly returned, but the state was actually smaller than U times the size of the encoding Y. And here we allow for a small slack C to disallow trivial attacks where the adversary can simply forget a few bits and guess them right before giving the encodings. So this basically says that A2 can only return that many encodings as the state can accommodate. So now to actually build a replica encoding scheme we use as tools a trapdoor permutation and a random permutation. And for the sake of concreteness let's think of RSA as the trapdoor permutation and all our constructions and the adversary will have oracle access to a random permutation T and its inverse. So here is our first attempt at constructing a replica encoding scheme. So we take the file to be encoded M, append some randomness R called the random permutation T and then sample keys for the trapdoor permutation and apply it in the inverse direction using the secret key. And this output Y is said to be the replica encoding along with the public key of the trapdoor permutation. Now if this is our replica everybody can decode by simply applying F in the forward direction using the public key and then calling T inverse and obtaining M. So what about soundness? Why should this work? The intuition is the following. Recall our soundness game, the first stage adversary outputs a file M and this is our construction now we are going to apply a random permutation T and F inverse on the output of T. So Y, I is our encoding. So the adversary gets a bunch of YIs. It has access to T and T inverse and outputs a state that is given to A2. And now if A2 outputs a bunch of perverted encodings let's say for now that the adversary behaves in the following restricted way. A1 forgets all information about one replica. So let's say that A2 returned all N replicas correctly but the size of the state was only as much it could fit N minus one replicas. So the state forgot all information about say the i-th replica which means the state has no information about yi and zi. And now if indeed A2 returned yi we know that state has no information about zi. So A2 must have made a query to the oracle T in the second stage of the soundness game. And here we program the response to the query to embed a challenge image which is the image that we're going to invert in the reduction. But here we assume that the adversary behaves in a restricted way. What about soundness for general adversary that can store arbitrary pre-image information of the replica encoding? We only want to assume that the state that the adversary outputs the size of that state is less than the combined state of the number of replicas that we retrieved from A2. And now we cannot actually embed a trapdoor permutation challenge and the security of the trapdoor permutation does not give us soundness. So what can we do? The final idea towards our construction is to repeat this initial idea sufficiently many times. So this was our initial construction. We applied T and then f inverse on the output of T. Now instead of stopping here and outputting y we take y and apply T and f inverse again. And we do this a bunch of times, say r number of rounds. I'll talk about what r should be later. And after r number of rounds we output y and the public key of the trapdoor permutation as the replica encoding. So this is our final construction to construct a replica. We sample keys for trapdoor permutation and then apply f inverse and T in an iterative fashion and obtain the replica encoding. So what should be the number of rounds and why does this give us soundness? So recall our first construction did not already give us soundness because the adversary could store arbitrary pre-image information. But now since we are calling the random permutation T many times in constructing one replica the hope is that the adversary has to store pre-image information at every round. And if the number of rounds is sufficiently large at some point the amount of information that the adversary should store exceeds the bound that we need for replicated storage. So here is the high level idea of the proof. Recall our construction calls T many times in constructing one replica. And now we argue that if the state that A1 outputs is too small then it cannot remember all the answers to the queries that was made to T by A1 in the first stage of the game. And because decoding is efficient and since A2 actually gave us all the encodings by decoding we could extract from A2 all the outputs of all the intermediate outputs of T from one replica. And what this means is that A2 must have query T in the second stage of the soundness game because we can extract all the Zs. And now we reason about the size of the state and account for the state entropy budget which is small and argue that some response of T to the query that A2 makes must have full entropy in the view of A2 even given state information. And this is the response that we reprogram in our response to the query to T to embed the challenge image in our security reduction. What should R be? What should the number of rounds be in the paper? We show that by suitably setting the parameters in particular if R is greater than KN where K is the security parameter and N is the number of replicas then the amount of information the adversary must store must exceed the replicated storage bound and this gives us our soundness. So how do we deal with large files? What if the file to be encoded M does not fit inside a trapdoor permutation or the random permutation? So what we do is we first apply a large random permutation H on the entire file and now apply our construction which is iterating T and F inverse blockwise. So we split the output of H into multiple blocks and then apply our construction to each block independently. But the H here which is applied on the entire M ensures that the adversary cannot de-duplicate multiple blocks that occurs across different files. Now that we have a replica encoding scheme we can define and construct a proof of replication scheme. So proof of replication has a create algorithm that takes a file, a replication parameter and outputs in different replicas to be stored and some verification information for the client and there is a retrieval algorithm that takes the replica and retrieves the original file and we have the usual notion of completeness that the M prime that retrieved returns must be the same as the original file and there is an audit protocol where the server can convince the client that it is indeed storing all the replicas and then we define a notion of soundness for proof of replication which is the following. So again we think of a two-stage adversary A1 and A2 and A1 outputs a file that is to be stored in a replicated way and we create our replicas and give the YIs to A1. Again like in the replica encoding soundness notion A1 outputs a state which is given to A2 and now we say that the adversary wins the soundness game if the following condition holds. If the state is too small that is smaller than the number of accepting proofs that the prover gives or if the extractor extracts a number of replicas that is smaller than the number of accepting proofs that the adversary gives. So what this, I'm sorry. So what this definition is intuitively saying is that the adversary wins the game only if the number of accepting proofs he gives is smaller than what the, is larger than what the state could accommodate or if the extractor could not extract the number of replicas for which the adversary gave accepting proofs. Now to construct a proof of replication scheme we take our replica encoding scheme and together with the proof of retrievability our construction works. So we take the underlying file, use the replica encoding algorithm to get a replica encoding and then use a proof of retrievability on top of the encoded replica and ship off the encoding to be stored at the server and the verification information for the client. And for soundness we rely on the soundness of the replica encoding scheme and the soundness of the proof of retrievability scheme. So at a very high level we have that each replica is incompressible because of the replica encoding scheme and each of these incompressible replicas are extractable because of the proof of retrievability on top of it. So this is our construction which has public verifiability without timing assumptions. But this is in the setup where the encoding itself is honest. So does this mean that we have to trust the client and can we trust the client? So what this means is the following. In our setting we had a client who constructed a number of replicas sent it to the server and these proofs were publicly verifiable because the server could convince other parties that it was actually storing many replicas. But the soundness here for parties other than the server but the soundness of the proof for parties other than the client who actually encoded holds only if the encoding is honest and this does not work directly in the file coin setting because in the file coin setting the client could actually collude with the server and convince everybody else that it's actually storing many files when it's not dedicating enough space. So one idea to overcome this is to involve multiple users instead of having one client compute the encoding we can have multiple users jointly compute the encoding and the hope is that maybe we will have soundness if at least one user is honest. And in the paper we sketch two approaches to multi-client encoding and I'll say a little bit about what they are. So in sequential encoding we have one party compute an encoding using his own trapdoor permutation key and then a second party comes along takes this output and computes an encoding on top of it. And basically each user can add his or her own layer of encoding and consecutive users can encode the previous output. And if one of the users is honest then the server does not know the trapdoor permutation key of at least one user and it's essentially our main construction but with more number of rounds. I don't have time to talk about parallel encoding but you can see our paper for this. I'll just conclude by saying that in this work we defined a notion of replica encoding scheme gave a definition of proof of replication without timing assumptions under construction that satisfies public verifiability. Thank you. So thank you very much for the nice talk. We have time for one quick question since we already started late. Is there one quick question? Then please go to the mic and say, you're not, okay then let's thank the speaker again.