 So I'm going to talk about non-interactive publicly verifiable secret sharing with thousands of nodes. I'm Shai Alevi, and this is joint talk with Craig Gentry and Vladimir Voshchevsky. So the overall goal of this line of work is to implement secure multi-party computation in a crowd where you have maybe thousands of parties participating here. Why would you want to do that? Well, it's useful if you're in open systems like blockchains or maybe other coalitions. But I'm not going to dwell into the motivation. Instead, I'm going to try to describe to you, suppose you wanted to do that, how would you go about doing that? Now, the hard part is manipulating secret information. And the core of that is how to share a secret. So this is the focus of our work of verifiable secret sharing scheme. What is verifiable secret sharing? So just like any other secret sharing scheme, you start with a dealer that has a secret called S. And you end with the parties that hold share of the secret. And in this case, Shamil secret sharing. So there is an polynomial f of x of degree t, t is a parameter. The evaluation of f at the point 0 is your secret S. And party i knows the evaluation of f at i. This is verifiable in the sense that shares of the honest party sit on a degree t polynomial and therefore can be reconstructed later, even if the dealer is faulty. And faulty here is malicious. The dealer can do whatever they want. Some additional properties that are useful if you may use them in the secure computation protocol are publicly verifiable. Everybody that sees the communication can tell if the dealer was faulty or not. And non-interactive. Non-interactive is just saying that the dealer can broadcast a single message and then go away. There is no back and forth. Now, the communication that we're thinking of is broadcast channel. So for us, if you want to send a message, you broadcast it. This is the only way to communicate it. So in this setting, there is a generic way of doing things. I mean, the dealer needs to distribute the shares. How can I broadcast what it's going to do? It's going to broadcast an encryption of the shares. So encrypt f of i under the public key of party i. And then just send a single message to all of them. And in addition, you attach proofs, non-interactive, zero-knowledge proofs that the encrypted values lie under the great key polynomial. So this is a single message. Everybody can verify all the proofs if the dealer cheats in any of them gets disqualified. And then the honest parties can choose some kind of default value, maybe the zero polynomial, what have you. And then when you want to reconstruct the secret, well, everybody saw all the ciphertext. So now if I want to reveal my shares for the purpose of reconstruction, then I'm just going to add a proof that the share that I just revealed is indeed the decryption of the ciphertext that you also. So this is the obvious, perhaps, way of doing non-interactive publicly verifiable secret sharing. And if you want to implement it, then, well, now you need to show me how to encrypt, how to improve. And if you want efficiency, then you need efficient proof and efficient encryption, et cetera. There's a lot of a pile of work about how to do exactly that. But most of it is not concerned with the parameter of the gene that we care about, where there's a lot of parties. So almost all pile of work of systems that are very efficient for small number of parties, but choke once you hit about 100, let's say. Perhaps some exception that was the script log-based encryption, where the secret is shared in the exponent. So when you decrypt and recover, you can only recover s times g, the representation of s in the group, rather than s itself. This is good enough for some application. It's not good enough for others. In our case, we want to do a straight-out VSS. So you really want to recover the secret s itself. Before showing you how we do that, let me just briefly sketch the techniques that we present here. What are and how well do they perform? So we have an implementation of our techniques. They're rather naive. They're signal-threaded, single-threaded. The exponentiation is not fast, et cetera, et cetera. But it was designed to show feasibility. You can easily, like a forex factor, maybe more. It's embarrassingly correlizable. Multi-threading should get you. But what you get is 1,000 parties. It takes about half a minute to prove and maybe 20 seconds to verify. So not blazing fast, perhaps, but entirely feasible. In terms of bandwidth, remember, we broadcast everything. So bandwidth is at a premium. So it's OK. Not great, but fine. The specific parameters that we chose for 1,000 parties you have about Lx for expansion factor, meaning you're broadcasting about eight times as many bits as it would take you to just send the shares in the clear. And the more parties you have, the better is the expansion factor it converges to 2x as the number of parties grow. For example, with 6,000, you already have like a 3x factor. So it gets there. And with that, let me say a few words about how we do that. And I need to describe to you how to encrypt. And I need to tell you how do we efficiently prove the things that we need to prove. Encryption will be done with lattice-based encryption. That might be a surprising in the sense that we want efficient bandwidth. And lattice-based schemes don't do that usually. But I'll show you with the packing techniques of Pekka, Bekutonata, and Waters we can do quite well. And then Avaris set of tricks to get the proofs to run faster. Let me remind you how the encryption works with TVW packing. So in this setting, you want to pack multiple plaintext element in a single ciphertext so that you can encrypt them all together and decrypt them all together. Let's say that you're trying to encrypt L elements and you have security parameter lambda. So first of all, we would think of this as working in the common reference string model. So with it is a common reference string matrix, m by lambda matrix, a m as you can think about it as more or less the same as lambda. And it's public and it's random and it's out there and everybody knows what it is. And the secret key is an L by lambda matrix of small elements. So it's a secret key of small elements. It's not in all the applications. But in our application, we need it to be small. In order to generate the public key, multiply the secret key by the common reference string, you add a small noise matrix, again, matrix with small elements. And what you get is a matrix that can be called B. And we publish this matrix B. And it's convenient to think of the public key as both matrices together. So A concatenate with B. The property that makes this a good public key is if you multiply it by the secret key concatenated with the identity, then what you get is a noise matrix. So it's a matrix that looks random under the hardness of a distinguished LWE. But you know linear combinations of the rows that give you small vectors. That's what a regular public key is. How do you encrypt? Well, you choose another random small vector. This time, you're gonna multiply it on the right of the public key. And you're going to add your plain text. Specifically, you're going to add the plain text in the rows that correspond to the matrix B. And you're gonna pad it with zero in the rows that correspond to the matrix A. And that gives you the Cypher text. Now, this is one version of public encryption. We are gonna actually use a slightly different version where you add a little bit of noise to it. The reason we do that is essentially just get better parameters as this one. How do you decrypt? You just multiply the secret key by the Cypher text. And if you manipulate this expression, you see that what it gives you is the original vector X with all the plain text elements plus some vector that has low norm. So it's X with a little bit of noise. And if your X was encoded to begin with, then you can recover the information from this noise vector. So this is how regular encryption works. Notice that the Cypher text vector has dimension L plus security parameter. And you use it to encrypt L encoded by text elements. So bandwidth-wise, you're losing in that, you had to encode your elements and you're losing in that you increase the dimension by security parameter. In our case, the encoding that we use is a little bit different than what Legev was using. And it entails a two X factor in bandwidth. And then the more L is relative to lambda, the closer you are to a factor of two expansion ratio. This is why when there are more parties, the bandwidth gets better. Let's talk a little bit about what happens in the multi-user setting. Because PVW was done in the setting where the single party has the entire secret key. In our case, we have L parties. And the nice thing about PVW is it works quite well. You just give every party I one secret key vector. So, and we're thinking in our head about all of these vectors being part of the one secret key matrix. So I have a vector SI, I'm computing and broadcasting the public vector PI, which is just SI times A plus a lot of noise. And all of these BIs are included in the global public matrix. And we're just gonna concatenate them and put them together in a matrix. So it's exactly the same, except now every party knows a single row of this secret key matrix. Encryption is still exactly the same, but now the IF plaintext is intended for party i. So I'm going to put the share that I want party i to get in the IF place plaintext slot. And decryption every recipient can get can decrypt as usual. So you just do an inner product of your secret key vector with the ciphertext. And what you get is the plaintext that was meant to be sent to you plus a level of noise. And again, if it's encoded, then you just decode and get your things. The one thing that I still need to tell you about is security. Security in PVW was proven in the regular model where a single party holds the entire secret key, but here we have a different setting. I have my own secret key and I may be dishonest. So maybe using my secret key, I can learn things about the encryption randomness that will allow me to attack the encryption for others and need to analyze that. Turns out in an R application, that's not really a problem. The reason it's not really a problem in R application is because R application any old files, all the parties to prove that they generated the key correctly, which means I need to prove that the BI that I broadcast was indeed obtained as SI times A plus EI where SI and EI are low normal vector. And I'm going to use the proof of knowledge for that. So in the proof of security, people can extract from me SI and EI. And in that setting, we can show that PVW encryption works beautifully. Do not violate the security of others with a little bit of twist in that the bottom of the noise, additive noise that you do in encryption has to be higher norm than the top. So here is our system, exactly the same as PVW except the E vector has a bottom corresponding to the one that uses to mask out the plaintext has higher norm than the others. And we need some noise flooding, if you know what that is. But everything else is completely as usual. Plaintext XI is intended for party I, the bottom is bigger, the crypt as usual, the parameters have to be set so that you can tolerate this high level of noise. That's the encryption that we use. And as I said, you get very good band, relatively good band with, because as the, you have more and more parties than the expansion ratio tends to two. And you get very efficient encryption because all the operations are just linear operations. And moreover, it makes it a lot easier to prove things about the encryption. I need to prove, collect encryption, collect encryption, collect TK generation, et cetera. So let's talk about proofs. We need a lot of proof sub-protocols to prove that they generated my keys correctly, I encrypted correctly, I decrypted correctly. I need to prove that the encrypted values form a valid secret sharing. So I need to prove some linear statement saying that they all lie on some polynomial of low degree. The building blocks that we use, we use a hybrid of discrete log and lattice-based proofs. Discrete log-based bullet proofs for proving the underlying linear and quadratic relations that we need. And one thing that helps us to make keeping simple is that the group order that we use for bullet proof, the discrete log group order is the same as the encryption modules we use, I guess. So we can always work in the same place, in the same algebraic structure. And then we use this lattice-based proof of approximate norm, the cold lattice-based, even though there's nothing lattice-specific about them, they're just used in the context of lattice-based scripting. And then we have combined them in various ways. There are trade-offs between tightness and complexity and need to aggregate all the proofs into just a handful of them in order to execute them. I'll talk a little bit about it next. Let's start with the building blocks, one building log-based bullet proofs, and we use it in order to prove linear and quadratic relations. So linear relations, we have a committed vector, we have a public vector, and we need to show that their inner product is some public value B. Quadratic proofs is very similar, except now we have two committed vector and we need to show that their inner product is some public value B. Roughly speaking, quadratic proofs cost about twice as much as linear and the reason for that is that you just commit to twice as many values. The lattice-based proofs that we use are approximate L infinity proofs. Here we have a bound B and a commitment to a vector and you want to prove that the L infinity norm of the vector is bounded by B. The honest prover needs to use a short of vector. So if you want to prove a bound of B, you need to use an honest prover, you need to use a vector whose actual L infinity norm is B over gamma where gamma is the size gap of your, and gamma is a parameter again. So this we use, we just take it from the literature and use it, and now on top of that, we build all the proofs. So the first thing, which is fairly standard, except as Zabin would say, this is the first time that we find that this very obvious approach actually works to do something useful, is use these tools to get a tight L2 norm proofs. So I want to prove the L2 norm of a vector and I want to prove that exactly without the gap. Here we're going to use sum of squares. So remind you that for every integer n, there exists for other integers, a, b, c, d such that n is the sum of the square of these four. How do we use that? If I have a vector x and I want to prove that the L infinity, L2 norm of the x is bounded by some bound v, then I'm just going to pad x with these four element a, b, c, d such that the norm is exact to be. And then, so I'm going to get a vector y, which is the concatenation of x with these four elements and I'm going to show that the inner product of y with itself is B square, which is a quadratic proof. One issue is that bullet proof can prove quadratics modulo p. We need to prove that the inner product is B square over the integers. Here is where we use the approximate size proofs. We're just going to show that this vector is relatively small, indeed small enough so that you do not get a wrapper on would be. Now we know that the relation of course over the integers and we're done. So that's a very natural thing to do. There is one twist here. It's not exactly enough to show that the inner product of y with itself is B square. We need a little more than just the quadratic proof. The reason is the quadratic proof, if you look at it as a black box, what it does it gets two commitments and it proves things about the inner product of these two vectors. Well, if you're a cheating prover, there's nothing that forces you to commit to the same y in both of them. So in order to fix that, what we're going to do is we have the verifiers and the shift vector delta. And then the prover will prove that y plus delta inner product of y minus delta is the B square that we have before minus the non-square of this delta vector. And it's very easy to transform C1 and C2 into the commitment to y plus delta and y minus delta. And that's all the problem. Now, if I didn't commit to the same thing, then the probability that it would be able to prove it is negative. Right, let me go describe something slightly more interesting. And this is how you prove smallness of a very high dimension vector. So suppose we have a vector of dimension D, which is really huge. If I wanted to prove L2 normally the way I just described, well, then I need to have a quadratic proof for a dimension D vector and that's expensive. I want to save a little bit. So what I do is the verifier will send a random small matrix with entries zero and plus minus one, which is a compressing matrix. It's security parameter by D. The prover compute the low dimension vector V as W times R and commit to it. And then the prover proves two things. One is that VE, the committed vector V is indeed equal to the committed vector W times R. Well, that's just linear proof at a high dimension, but linear not quadratic, so half the cost. The other one is it proves that V has low norm. This is the smallest proof essentially quadratic, but low dimension, so it doesn't cost a lot. So what we get is roughly a factor of two X improvement versus high dimensional smallest proof. Why does that prove anything about what we wanted? Well, by Johnson-Lindlstrasse, the L2 norm of W is tightly concentrated around the L2 norm of, so the L2 norm of U is tightly concentrated around the L2 norm of W times some factor that depends on the security parameter. So if you have a bound on the size of U, you get a bound on the size of W with a very, very small. Okay, the last thing that I want to tell you about is aggregating bullet proofs. We have a lot of sub-protocols. We need to prove a lot of properties. Each sub-protocol implies some linear relations, some quadratic relations, and we have some variables that appear in these, multiple of these relations, of course, but each variable is only connected once. So we show in this setting a series of simple transformations that converts this to just a single linear relation proof for all the variables that only appear in linear statements and a single quadratic relation proof for all the other variables, and you need to throw in one single additional variables that appear in both. So you can convert all of the myriad of many, many proofs into just two of them and then you run protocol just twice. And with that, let me summarize we implemented a non-interactive, publicly verifiable secret sharing. It remains feasible even, you know, thousands of those, I'll explain in about 2000, but you should be able to do it with 100,000 and still, you know, coming tomorrow and see it finishing. It uses reges with PVW packing for encryption in the multi-user setting. So there's a security analysis that's needed. It uses a hybrid of lattice and discrete log-based proof and a very large bag of tricks to make them run faster. And maybe we can actually use it to do a secure MPC in big crowds, but there's a lot of work remains. In particular, if you want to use it in blockchains, there are a ton of extra work that still remains to be done. This is really just the core of the system. And with that, I am done. Thank you very much.