 Hi, I'm Lisa, and I will be introducing our work, Storing and Detieving Secrets on a Blockchain. This is a joint work with Vipul Goyal, Abheramkotapalli, Ryan Parno, and Yifan Song. One of the main contributions in our work is a new secret sharing scheme. Such schemes enable one party to distribute shares of a secret to end parties. If the secret sharing scheme has threshold T, it must be possible to reconstruct the secret using T plus one shares. At the same time, a secret sharing scheme with threshold T ensures that an adversary in control of T out of end parties learns no information about the secret. While secret sharing is great, it seems insufficient when secrets must be stored for a long time. This is where proactive secret sharing schemes, PSS, comes in. Similar to traditional secret sharing, PSS schemes enable one party to distribute shares of a secret to end parties, such that any T plus one shares are enough to reconstruct the secret. And at the same time, an adversary in possession of T out of end shares learns no information about the secret. However, proactive secret sharing schemes additionally consider the setting where the adversary may eventually corrupt all participants over time. While corrupting no more than a certain threshold at any given time. Unfortunately, even PSS is often insufficient, especially for obligations in which the set of parties who hold the secret shares might change over time. To achieve security in this setting, dynamic proactive secret sharing schemes are used. DPSS schemes proactively update the secret shares held by the parties and allow changes to the set of parties holding the secrets. In this work, we introduce FAB DPSS, which stands for fast batch DPSS. It is a highly optimized batch DPSS scheme. As you can see, among the schemes which allow the highest possible adversarial threshold of one half, our protocol has the best communication complexity. It is also the most concretely efficient scheme so far. In addition to the FAB DPSS construction, we propose EVAP, a blockchain based DPSS application, which can be seen as an alternative to acceptable witness encryption. Witness encryption has been introduced by Gargaral and it allows one to encrypt a message with respect to a particular problem instance. Such problem instance could be a Sudoku puzzle in the newspaper or an allegedly bug free program or more generally any NP search problem. If the decryptor knows a valid witness for the corresponding problem instance, such as Sudoku solution or a bug in the program, she can decrypt the ciphertext. Witness encryption is called extractable if it additionally provides extractability, a strong security property which we'll define later. Note that there are numerous applications which need this property, but unfortunately there are no known practical, extractable witness encryption schemes and no constructions based on standard assumptions. EVAP can be seen as something similar to extractable witness encryption, though based on blockchains. In this talk, we will first look into the main ideas behind our FAB DPSS construction. I will then introduce the EVAP primitive and provide an overview of our construction, which satisfies the EVAP definition. We will finish by discussing applications of EVAP and FAB DPSS. We will first briefly recall the definition of DPSS. As I mentioned before, such schemes allow clients to distribute shares of a secret to end parties, so that an adversary in control of some threshold number of parties learns no information about the secret. The set of parties holding the secrets is constantly changing. The adversary can release some parties, use as regain control of their systems, and corrupt new ones. A DPSS scheme consists of the phases setup, handoff, and reconstruction. During each setup phase, clients share secrets to the parties currently holding the secrets, known as a committee. During each handoff phase, committee members change and the old committee passes secrets to the new committee. During each reconstruction phase, the current committee engages in interaction with the client who asks for the reconstruction of a secret to allow the client to learn the secret. At a higher level, the security of the DPSS scheme requires that it should always be possible to recover the secret, and an adversary should not learn any further information about the secret beyond what has been learned before running the protocol. In our work, we consider a computationally bounded, fully malicious adversary A, with the power to adaptively choose parties to corrupt at any time. A can corrupt any number of clients distributing secrets and learn the secrets held by the corrupted clients. The adversary is allowed to corrupt less than half of each committee. Note that the handoff phase is particularly challenging, as during this phase, not only T, but two T parties can be corrupted. T parties in the old committee and T parties in the new committee. We start with the semi-honest case, where parties follow the protocol, but try to learn some extra information about the secret. 50PSS is based on a Chamez secret sharing. We call that in essence a degree D Chamez secret sharing is a degree D polynomial. The secret is encoded at 0.0 and I share is encoded at 0.I. The foundational idea in 50PSS are what we call coupled sharing. By this, we mean two sharing which have the same value, even though the particular shares which lead to this value are different for the two sharing. Now to refresh a secret, a sharing of a secret S, the new committee can prepare a coupled sharing of a uniform random value R. The old committee will receive shares of one part of the coupled sharing and the new committee the shares of the other part. The old committee can now reconstruct and publish S plus R. And the new committee can set the new sharing to be S plus R minus the sharing of the other part of the coupled sharing. Since both parts of the coupled sharing lead to the same value R, the resulting sharing is still the sharing of the secret S. Now the question is how do we prepare the coupled sharing? A strong approach is the following. Each party of the new committee prepares a coupled sharing of a uniform random value and distributes the shares of one part of this coupled sharing to the old committee and the shares of the other part to the new committee. Each party in the old committee can now compute the sum of the shares that received, same for each party in the new committee. Since we are in the semi-honest case, these sums give us a coupled sharing of a uniform random value. However, note that this approach is wasteful. For a total n number of parties in each committee and for an adversarial threshold T, at least n minus T parties in the new committee are honest. Those it would be nice to obtain n minus T coupled sharing instead of only one. To achieve this, we build upon an idea from the work of the Armgard and Nielsen. In their work, parties need to prepare batch of random sharing which will be used in an MPC protocol. All parties first agree on a fixed and public fundamental matrix of size n times n minus T. An important property of a fundamental matrix is that any sub matrix of size n minus T times n minus T is invertible. Then to prepare batch of random sharing, each party generates and distributes a random sharing U. All parties multiply the vector of the shares they received by M and take the values of the resulting vector as output. Since any n minus T times n minus T sub matrix of M is invertible, given the sharing provided by the corrupted parties, there is a one-to-one map from the output sharing to the sharing distributed by the honest parties. Since the input sharing of the honest parties are uniformly random, the one-to-one map ensures that the output sharing are uniformly random as well. In the full malicious case, multiple challenges arise. For example, we need to deal with the case when a malicious committee member distributes shares that do not correspond to a degree T polynomial. We also need to deal with the case when a malicious party distributes shares of some value to the old committee and shares of some other value to the new committee so that the two sharing are not a valid couple sharing. At a high level, we solve these issues by efficiently checking whether a number of couple sharing are correct by checking whether their random linear combination is also a couple sharing. Additionally, we rely on polynomial commitments, which can be used to transform a Plain Secure- Alchemy Secure sharing into a verifiable one so that an incorrect share can be identified and rejected by all parties. We present and formally prove FAB DPSS secure. We note that among the robust DPSS schemes, which provide the highest possible adversarial threshold of one-half, our batch construction achieves the best amortized complexity of N while the state of the art achieves all N squared. Simultaneously, we achieve the same non amortized complexity. Both works achieve all N squared. In addition, our evaluation shows that FAB DPSS is also concretely efficient. All operations complete in seconds and we outperform the state of the art by over six times. As I mentioned before, in addition to FAB DPSS, we propose EVAP, an alternative to Extractable Witness Encryption. Specifically, we ask the following question. Can users store secrets and specify release conditions for them such that possibly other users can retrieve these secrets if and only if they are able to satisfy the release condition? And obviously, our goal is to achieve this without relying on trusted third parties. In EVAP, Extractable Witness Encryption on a blockchain we distinguish between users who deposit secrets, we call them depositors, and users who request that a secret be released. These are the requesters and a changing set of blockchain nodes minus who are executing these requests. An EVAP system consists of three possibly randomized and interactive subroutines, secret store, secret handoff and secret release. These are similar to the algorithms used by DPSS with the difference that now a release condition is specified by the depositor. Specifically, secret store allows a depositor to specify a release condition and distribute a secret among a set of miners, which we call the committee in the following. Secrets handoff is periodically executed by the miners to hand over all stored secrets from the old committee to the new committee. Finally, secret release is used by the requester to ask for the release of some secret. Miners check whether the requester holds a valid witness, and if so, as a result of the interaction with the miners, the requester privately obtains the secret M. In our paper, we provide a game-based security definition for EVAP. Intuitively, this definition states that if an adversary is able to distinguish between the protocol executed with secret from zero and the protocol executed with secret M1, then we can also use this adversary to extract a valid witness for the release condition of the secret. Intuitively, this notion is quite similar to the acceptable security of witness encryption, which states that if an adversary can distinguish between two ciphertexts, then he can also extract the witness from the corresponding problem instance. We designed a protocol which satisfies the EVAP security definition. It uses blockchains and DPSS. The initial committee are miners who mined the most recent M blocks in the underlying blockchain. Given a secret message M and the release condition F, the depositor stores the release condition F on the blockchain and secret shares M among the miners using the secret storage setup algorithm of the DPSS scheme, FEP DPSS in our case. During the protocols periodically executed hand-off phase, the secrets are passed from the miners of the old committee to the miners of the new committee using the DPSS hand-off algorithm. The new committee consists of the miners who mined the most recent M blocks. This keeps the size of the committee constant and allows all parties to determine the current committee by simply looking at the blockchain state. Finally, to retrieve a stored secret a requester needs to prove that they are eligible to do so. Note that this indeed poses the challenge. An insecure solution is to just send a valid witness W to the miners. However, a malicious miner could then use to provide that witness to retrieve the secret himself. To solve this problem instead of sending the witness in clear, the user proves that they know valid witness. Thus, while the committee members are able to check the validity of the requests and privately release the secret to the requester, the witness remains hidden. Note that this can be done using Nizik's non-attractive zero-knowledge proofs. Such proofs allow one party, the prover, to prove the validity of some statement to another party, the verifier, such that nothing except for the validity of the statement is revealed. However, simply using Nizik's is still not enough. As a malicious miner could now use the obtained Nizik to simply submit the same Nizik and retrieve the secret. To solve this issue, we incorporate the public key of the requester in the Nizik and utilize only Nizik's switch-proof non-malayability so that only the user with the specified public key is able to obtain the secret. Last but not least, we use eweb to enable a bunch of exciting applications which rely on extractable witness encryption. In our paper, we explain how eweb can be used to achieve timelock encryption, which allows one to encrypt a message such that it can only be decrypted after a certain deadline has passed. eweb can also be used to implement the so-called statement switch which under a certain condition triggers a process such as making public or deleting some secret data. Using eweb, it is also possible to obtain fair exchange and fair MPC. Fair exchange ensures that two parties receive each other's inputs atomically and fair MPC ensures that either all parties receive the output of the protocol or not. eweb also makes one-time programs possible. These are the programs that can be run only once. And finally, we show how non-depudiation proofs can be done. They ensure that parties cannot deny requesting and obtaining certain data. In our work, we also have some other examples for this please take a look at our paper. Note that prior to our work, there already existed theoretical constructions which explained how these applications could be achieved using extractable witness encryption and in many cases blockchains. However, with eweb, you can make implementing these applications more realistic. That's all I have. Thank you for your attention.