 Hello, I'm Shai Halevi and I will talk about can a public blockchain keep a secret? This is joined to work with Fabrice Benamuda, Craig Gentry, Sergei Gorbunov, Hugo Kravchik, Cheng Yulin, Tal Abin, and Leonid Rezzi. So what is a blockchain? A blockchain is many different things to many different people, but for us now, this is just a computing platform. There's a system there that you can compute things on. In a little more detail, we're talking about a public blockchain, which is a distributed network of potentially many nodes. How many? When we want to design the system so that it can be as many as you want, hundreds, thousands, million, it can work either way. And these nodes are continuously deciding on things. They're continuously computing stuff and the things that they're deciding on are called transactions, decisions are made by consensus and they are published in blocks and then visible for everybody to see. In other words, we have a broadcast channel. In fact, in this talk, a blockchain is nothing but a large distributed system with only broadcast channel. If you wanna say anything at all, you need to broadcast it for everybody and the broadcast is authenticated so everybody knows who broadcasts what message. What we want is to use the blockchain as a computing platform and for us cryptographers, a computing platform is just a trusted party. We have many parties, a cat, a dog, a donkey, each one with their own inputs, which could be secret. They're going to give these inputs to the trusted party and the trusted party will compute whatever function those clients want to compute and then would announce the result for everybody. This is what we want to do with our blockchain. Can we do that today with public blockchains? Well, not really. Blockchains are very good when what you care about is integrity or agreement or immutability, but secrecy is much harder and secrecy is the focus of this work. Specifically, in this work, we have a very, very, very basic setting. We have a client, the client deposit a secret at the blockchain and all the blockchain needs to do is just to keep it a secret at least for a while. It should be revealed only when the time is right or more generally used only in some prescribed manner. So here's an example to keep in mind. I'm going to publish a puzzle for everybody to try and solve. I'm going to deposit the solution to the puzzle with the blockchain and I'm gonna tell the blockchain, well, if nobody solves this by next week, please reveal the solution to everybody. If the blockchain can do that, that can form the basis for many applications. And then if you can keep the secret, you can start computing on it and then you can do many, many different things. What do we want in terms of security and efficiency? Well, security is fairly simple. The secret should remain a secret, right? The adversary shouldn't know it, but the blockchain should still be able to recover it when it needs to. Of course, to do that, we need to assume that there is an honest majority, in our case, a large honest majority among the nodes in the network. And importantly, we are thinking of a mobile adversary. So our node can be good today, corrupted tomorrow than recovering and rejoining the good part the day after, et cetera. And the efficiency is more interesting. What we want is a scalable solution, which means that the total communication that's getting broadcasted and also the per-party work do not increase as time go by or as more nodes join the network. As I said, we want to be able to design the system so that it can work no matter how many nodes we have. So we want the complexity to not grow with the number of parties. Another efficiency consideration that we have is what I call plausible practicality. By that I mean that we can at least hope to make it, to use it in practice. So I don't want to use something like obfuscation or witness encryption. Instead, here we seek solutions that are based on dynamic proactive secret sharing. So let me spend a few minutes and tell you what this is. Dynamic proactive secret sharing is a setting where you have a secret sharing. So there's a secret that shared among dynamically changing committees. So every day or week or hour or whatever, there is a new committee and that committee will share that secret. So you break the timeline into epochs, you change the committees every epoch and then at the beginning of each one of these time units, you do a share refresh protocol where one committee hands over the share, the secret to the next committee. And the requirement is that the secret remains secret as long as you have honest majority in all of these committees, even if different parties are compromised in different epochs. This is an active area with a lot of piles. Starting from the early 90s with the mobile adversary model and all the way to today, mostly in the context of blockchain, but not only, there was a lot of work. But the thing that's new in this work is all the prior work treats the committee selection itself as out of scope. Who says who is the next committee going to be? All of them just assume as a promise that all of the committees are honest majority and they treat the identity of the parties in the committee as just an input to the protocol. And the protocol doesn't need to do anything. It has this promise that the committees are mostly honest. In this work, we present this primitive of evolving committee proactive secret sharing ECPSS, which is nothing but a dynamic PSS plus a committee selection protocol. So in our case, we actually enforce honest majority and the committees with high probability as long as we have a sufficiently large global honest majority among all the nodes in the system. This is a new primitive that we present and that we construct. Here is the main point. If you remember nothing else, just remember this slide. The main technical challenge in doing this in our setting of mobile adversary let's imagine that the adversary is mobile with some corruption budget, which is some F fraction of the total number of nodes in the system. Think of F as one quarter. So for scalability, as I said, we want the complexity to not grow with the number of parties. So we're going to choose a small committee to do the work for the entire system. And we somehow gonna choose this committee at random so that it represents the system. But the point is the committee is small. In particular, much, much smaller than an F fraction of the nodes. We do not want the size of the committee to grow with the number of nodes. Well, if that's the case, then the adversary has enough budget to corrupt the entire committee if it knows who they are. So the challenge that we have here is to try to let the committee do its work. And in our case, its work is just to keep the secret and then to pass it on to the next committee. Without the adversary ever learning who they are until after they no longer know anything secret. So this is what we want to do. This is the main challenge that we're facing. And let's think a little bit about how to do that. So here is one tool that seems that it should be useful for us, self-selecting committees. This is already used in multiple blockchains. Think of a node as being AO. We would like a node to be able to self-select itself to the committee and then prove to everybody else that it actually deserves to be on that committee. So you can think about this is actually done in the context of many blockchains. Think of proof of work, right? There is a moderately hard puzzles that are announced. And then each node work for itself until it solves the puzzle. And if it manages to solve it well, now it's on the committee. And it can prove to everybody that it deserves to be there because it can publish the solution to the puzzle. So everybody knows that it's solved the puzzle and deserves to be on the committee. Excuse me. Similarly, a cryptographic sortation that's used in the context of a proof of stake blockchains. In this case, nodes will have VRF keepers where everybody else has public key and each node has the corresponding secret key. And those are keys for a verifiable random function. And now every time unit a public input X is announced, the node I will compute some random value, which is the VRF value with the secret key of that node on the public input X. You interpret that value as a value between zero and one. And then you're on the committee if your value is smaller than some epsilon, which is a system parameter. And if we have N nodes, we expect roughly epsilon time. And committee members, so if you make epsilon being order of one over N or C over N, then you expect some constant number of members on the committee. And moreover, the node can prove that it deserves to be on the committee because it shows the VRF and it shows the proof that this is indeed the right value of the VRF. And then everybody can check that. So that's nice, but it's not enough. For us, self-selection just doesn't work for the purpose of choosing the committees to hold the secret of the secret sharing. Why? Well, think about it from the point of view of the previous committees. If I'm on the previous committee, I don't know who's the next committee. How would I send them there my share? How do I forward this share? Well, I can forward it to everybody, but then also the adversary gets it, right? So there's no way for the current committee to send the secret forward to the next committee unless they know something about this next committee, but that next committee cannot talk because once they talk, the adversary know who they are and they can corrupt it. So what would you do? Just before we talk about what we want to do, here's another solution, just to show you that things are not that easy to solve. So maybe instead of me choosing myself to the committee, the previous committee can choose me. So every member on the committee can choose their successor on the next committee, for example, and then pass the secret to them, or whatnot. Well, that doesn't work either because well, if I'm a corrupted member of the current committee, then definitely I'm gonna choose myself or some other corrupted members to the committee next. And if I'm a good member, well, I'm gonna choose a random member perhaps, but then maybe with some probability, it's gonna be corrupted as well. So the fraction of people on the committee, it's a hundred of dishonest, people on the committee will keep growing until there is a dishonest majority and then the secret is lost. So that doesn't work either and question is okay. So what do we do? And the thing that we do is we imagine that we would have this wonderful communication mechanism, which we call target anonymous channels. What is target anonymous channels? It's just that the name suggests it's communication channels where the receivers are anonymous. So we have N, little N visible input port and little N hidden output ports corresponding to them. And there is some random assignment of the output ports to a little N subset of the big N nodes. And now if we have that communication infrastructure, then anybody can send on the IS input port. And the sender doesn't need to know who will receive the message, but the receiver will be the shareholder in our application. So this is a way of choosing an anonymous committee such that you can still send the messages. Okay, if this is what we want, how do we establish? So here is one way of doing that. Let's assume PKI again. And in this case, it's a PKI for an anonymous public encryption. An anonymous public encryption is just a standard public encryption. But when you see two different public keys and a cipher text encrypted under one of them, you cannot tell whether it was encrypted under the first public key or the second one. So this is the type of public encryption we want. We assume public infrastructure where everybody knows everybody else's public key. And how do you establish a channel to a particular node I? Well, you choose an ephemeral keeper, SK prime and PK prime. You encrypt this ephemeral secret key under the public key of the target node and you get some cipher text. And notice that this is the long-term key PKI is key of anonymous public encryption. So the cipher text doesn't betray who the node NI is or who the public key PKI is. And then you can broadcast the pair of the ephemeral public key PK prime and the cipher text encrypting the corresponding ephemeral secret key. And now anybody can encrypt a message under the ephemeral public key and broadcast it. And then the node NI can decrypt the cipher text and recover the corresponding secret key and then decrypt the message, but only the node NI. So that's nice. Other than whoever chose this keys, nobody should need to know who NI is. But who will do that? I mean, who's gonna choose NI and do all of this? I mean, we want, remember, we want NI to be anonymous to the other side. So how do we do that? And the way we do that is we set another set of committees whose job it is to choose those NI's and establish this target anonymous channel. We call that the nominating committee and our share refresh protocol that you run every time unit to pass the shares from one committee to the next, now would consist of two parts. First, the nominating committee. These members of the committee don't need to know any secrets. So here we can use the self-selection things. So the nominating committee self-selects. Each nominator N sub J chooses a random nominee N sub I from the big N parties and establish a target anonymous channel to that nominee. And then the old secret chair and committee, now they have these target anonymous channels, they can send messages on them and these messages will arrive at the new committee without anybody, well, anybody other than nominators really knowing who the target are. Let's talk a little bit about the resilience of this solution. So imagine again, an adversary that controls an F fraction of the nodes, then it controls roughly an F fraction of the nominators because the nominating committee is chosen a random. So roughly an F fraction of N will be corrupted. And again, we have the issue that the adversarial nominators choose adversarial nominees, while the honest nominator choose adversarial nominees with some probability F, right? So the chosen committee will have roughly a two F fraction of this honest node. Let me just stress that this is different than the solution that I said doesn't work before because this fraction doesn't grow. Every nominated committee is choosing a fresh, so it has F fraction of corrupted. Every secret sharing committee then will have two F fraction. So if we want to get honest majority on the nominating committee, sorry, on the secret sharing committee, we have to assume that the total fraction of corrupted parties is roughly less than a quarter and more specifically less than 0.29 because there are second order terms there. Our one point to note is that we cannot force the nominators to behave honestly. That doesn't work in our case because even if we do that, well, okay, now I'm on this honest nominator and you forced me to prove to you that I used VRF or whatnot in selecting the in my nominee. Well, okay, fine, I'll do that honestly. And then I turn around and corrupt that nominee that was honest before. I remember we were talking about the mobile address. So proof of proper nomination doesn't work in this case. Okay, so we have a way of choosing committees and now the only thing that's left is to actually pass the secret from one committee to the next. This is a DPSS. It's a little more complicated in our setting because we want a single floor, single message and there's no way for back and forth between members, et cetera. You can see in the paper how we do that. Essentially, each old committee member take its own share and then reshare that and then each member of the new committee take, gets shares of shares with everybody and recover the actual share of the secret from all of those. Each member of the old committee broadcast one message with secrets that are encrypted under the keys of the targeted anonymous channels and with a non-interactive zero knowledge proofs that resharing was done correctly. So everybody sees what I received in the previous time unit because everybody saw what was broadcast previously and I can once I already resharing my secret, I can tell everybody, listen everybody, I was Port Five in the targeted anonymous channel last time so everybody knows what things were sent to me and everybody sees the Cypher text that I'm broadcasting so I can make, do a zero knowledge proof a non-interactive zero knowledge proof that the input Cypher text that I received last time and the Cypher text that I'm sending this time are consistent. One point to note here is that the statement and the witness are short, meaning size linear in the committee size, it never grows with the number of parties in the system. The end result, scalable evolving committee PSS protocol assuming that the adversary controls less than 0.29 of the nodes. As I said, there's room for improvement here in terms of resilience. It can be implemented under the DH, ECR, WE or the partners assumption that we know and love except one caveat that we require both secrecy and anonymity to hold under selective opening at times. In our setting, there is a broadcast, the adversary sees everything that gets broadcast and then the adversary can choose who to corrupt. So both secrecy and anonymity needs to hold under selective opening attack. I will talk about it a little bit and it can considerably be made practical in the sense that we're not using anything that's out of the ordinary in implementing it. Moreover, this thing has a lot of applications. So both the architecture and the techniques are broadly applicable. You can use to do SQL MPC on public blockchain. You can have the blockchain signed. So you can have a message is signed on behalf of the blockchain relative to the well-known public here. Everybody can verify it. You can have the blockchain decrypt stuff and something compute even obfuscate computation. So by and large, these techniques actually let you use public blockchains as a trusted partner which is what we wanted. Let me conclude with just talking a little bit about anonymous public encryption under selective opening because it's a standalone open problem that we made some progress on but we didn't solve and it's a nice problem to try to solve. So recall that we broadcast ciphertext under some anonymous EKE and the adversary sees the public keys in the ciphertext and then decides who to corrupt. So the question is, can an adversary that only corrupts an F fraction of the keys nonetheless managed to read a lot more than F fraction of the ciphertext? So you see, this is the setting that we have. We have big N public keys and little M ciphertext. Little M is a lot smaller than big N and those ciphertext are encrypted under some of these N keys but the adversary doesn't know which ones because this is an anonymous public encryption. And the question is, can an adversary that corrupts only less than or at most F times N keys heat a lot more than F time M of the blue keys, the keys that were actually used to encrypt the message even though there are computationally hidden. We're talking about selective opening attacks. We have an adaptive adversary. It sees the keys, it sees the ciphertext that in open the keys one at a time. We can also talk about a semi-adaptive adversary that exactly the same thing except it decides on all the keys that it wants opening one shot rather than opening one at a time. These are two types of adversary that were discussed in the literature. And we know that in the context of secrecy, if what we cared about is a secrecy of the encryption scheme, semantic security does not imply secure secrecy under selective opening, not even against semi-adaptive adversary. And we ask the same thing about anonymity. Well, it turns out that the case for anonymity is different. We actually able to prove that if you have an anonymous public encryption, then a semi-adaptive adversary opening at most F times M keys cannot open much more than F times M, cannot open more than F plus epsilon for any fixed constant epsilon ciphertext encrypting keys except with negligible probability. We conjecture that the same holds for fully adaptive adversary, we were not able to show it. We actually have a reduction, but we think both, but we were not able to analyze the combinatorial game involved in that reduction. So it's conjecture, we don't know. It's a nice problem to work on. Some open problems and future work, of course, proving the conjecture would be really nice. Improving the solution. This we actually already know how to do follow-up works, improve the resilience, instead of requiring that the adversary controls less than 0.29, improve it so that any fraction smaller than a half would work while keeping the solution scalable. And of course, we don't want to just keep the secret, we want to compute on the secret. Another big future work item is to implement it. You need to choose the primitives, you need to implement the zero-knowledge proofs and all of that, there's a lot of work there, and maybe make it an actual realistic system that people can use. And that's all I wanted to say. Thank you very much.