 Okay, so this talk is about the verification of mixed net and today verification is a company, but the terms verification mostly people, most people think of verification as the mixed net, so feel free to use that. So before I say something about the mixed net I want to say something about electronic voting in general to give you some context where this fits in. So most electronic voting systems that you hear about, they basically consist of four different components. You would have a way to generate a public key somehow, a way to authenticate voters and check eligibility for voting and a way for forming your encrypted vote and then some way of tallying. And I wish to say something about this. So there are two basic ways of encrypting your vote, so to speak. One way is to have somebody else do it for you in advance and then print it on paper and so on. In this case you need a trusted postal service or a courier or something like that to provide you a piece of paper or in the polling station to provide you a piece of paper. So there are proposals like this, for example, the Prätta Votere system. And the other way is to have a device to encrypt it for you, so like a computer or your phone, in the obvious way. And of course we should worry about viruses and people are worried a lot about that in the e-voting community. So there are a bunch of different clever ways for the voter to verify that the vote was encrypted correctly. And since people are involved in this and notably people that are not so technical, these methods have been studied also with respect to usability. So one way to do it is to have a separate device to basically perform the encryption again and check that the result is the same. This is what they have done in Estonia. Another way is to challenge the encryptor. So you would have a machine that produces a ciphertext and then you can either use that ciphertext or you could tell the machine to show that it encrypted it correctly and verify that. So this has been used in the Wombat system in Israel and this is originally a proposal by Josh Bernalow. The third approach is to use something called a return code, which is basically like a personal MAC of your vote. So you submit your encrypted vote and you get back a private MAC of your vote. So you can see that your intended vote was actually encrypted and submitted. And then you need to verify that it was recorded so that the authorities don't remove your votes. So this can be done basically what you need is a bulletin board. And today we have all these cryptocurrencies which are perfect for doing this. So you can have a local chain that you now and then link into the great chain online. And this allows voters to verify that their vote is already there. What they submit will actually be counted. And finally, we need to tell you. And the result of all these input schemes, which I tend to call it, is some way of submitting a ciphertext that has to have some additional technical properties for proofs to work. But basically what we need is an algamal ciphertext or a malleable homomorphic ciphertext. So the one that is used in my code is the algamal cryptosystem, which has this nice homomorphic property. And I think that most of you know this cryptosystem, where at least you can recognize that this is basically the Hellman key exchange where you use the joint key as is as a one time pad. So instead of doing key generation and using some symmetric stuff, you just use that group element as it is once. And the nice property is this homomorphic property. So you can multiply two ciphertext and you're given a ciphertext which contains the product of the messages and the sum of the randomness. And the way we use it here is that we set m2 to 1, which means that we have re-encrypted the ciphertext. So keep that in mind. Okay, so David Chum came up with a beautiful idea called Mixnet. So here the idea is that we use multi-party computation to distribute trust and provide privacy. So the server somehow generate a joint public key. They accept some ciphertext, a list of ciphertext. All they do is decrypt and output the plaintext, but in random order. So it's really like usually I tell people it's like when you were a kid you have a hat and you run an election, you fold a piece of paper, you write your candidate, put it in the hat, shake the hat a little bit and turn it upside down and unfold all the pieces of paper and that's your election. This is what this is used for. Unfortunately, his particular construction was not particularly efficient or practical because we also want correctness property to be able to prove in zero knowledge that the whole thing went correctly. Okay, so here is an ideal Mixnet. So you have these nodes that you can view as senders or submission schemes used by voters and the result, they take the public key and the result is the list of ciphertext, each voter encrypts its vote and you get the plaintext in random order. So this box here is what we wish to accomplish with a protocol and we don't want to trust any single party so we distribute trust by multiple parties using multi-party computation. So here is the protocol. This is basically this original idea by Park Ito and Kurosawa to do this in this way. So here the servers generate the public key, the voters encrypts their votes and here I have ignored a lot of technical details and then the Mixervers take turns. So first the Mixer will re-randomize and permute the ciphertext. Then the next Mixer will re-randomize and permute the ciphertext and re-randomize and permute the ciphertext and so on. I think all of you know how Tor works where you have multiple layers of encryption and you strip off one layer after another, each server does this and randomizes. I this case instead of flipping off a layer we have a special envelope that we can kind of shake such that it looks entirely different after shaking. This is what re-randomization does. So this is what avoids the growth in length. But the main thing here is not really the length problem. The main problem that we wish to solve is to prove that this was done correctly. This is called the proof of a shuffle. And it turns out to be quite difficult to do this if you use layers of CCA to secure encryption. But for this construction it's much easier because you can use algebraic properties. Okay, and finally you decrypt. Okay, so this is basically the protocol that is implemented. Then there are lots of lots of details and before I go in to give you a little bit more about what this whole project has been about I want to give you the history here. So this actually started in Syriak. I was sitting at the ETH office and I had to check some equations in the proof of a shuffle, not the one that is used but similar. And those are very nasty. So I figured that I write a hack to check it. That at least it was correct. Okay, so I did that. And then when I went home I liked the program so I started working on this a little bit as a hobby. And then I started talking to Alon and Amnon and they wanted to use this. I talked to Ben Adida, we had these various discussions and I was hacking along during the evenings and so on. 2010 I released the first open source version and then this was used in the Wombat system for elections in Israel. There was an election for the Meretz Party leader, for example. Similarly a company run by some Spanish guys. It's called Envotes Now, previously Agora. They have used this for a long time and tallied 2.5 million votes. So they run a company using this open source version. Then we found some flaws in a system provided by the company Seitel to Norway in 2011. So they wish to replace the shuffling part of their system. And they didn't have anything to do that in reasonable time. So they asked me and then I had to improve things and start a company to protect myself legally and so on. So I was kind of dragged into this project in a way. And then I figured I'll try to go all the way. I started talking to people, I think some people from this more or less theoretical community and it was a humbling exercise. So I had a lot of advice and I improved the code and I did a lot of testing and everything. And now recently in 2017 it was used in Estonia. So this is the history. And here is a list of implemented protocols. But it's very important, I think, to remember that this is just the top layer. So there are some people here in the audience that are authors here. But there are also this huge literature of things that led up to this. So although the implementation is mine and a lot of tricks are mine and a little bit, some protocols, most of it is not my theory. It's not my ideas, let's say. So this is provably secure, it's well understood, but this is not really enough. This is an exact proof that gives you secure concrete security parameters and proves composition of all of these protocols for exactly the protocol that is implemented. Not some slightly different theoretical protocol, but exactly what is implemented, the real world crypto protocol. So this is something that I'm working on. So what about usability? So the functionality is really a black box. You can ask it to generate keys. These servers running as a box, okay. It can shuffle ciphertext without decrypting, it can decrypt without shuffling, it can do both. And every time it will output the zero knowledge proof that it was done correctly. And you can have different number of ciphertext processes as one block. If you have longer plaintext, you have to embed it in multiple blocks. So it's very flexible, I would say. So to deal with this, I wrote a user manual. And so everything is really well documented, I would say. All the commands, everything, this is very polished stuff. And when I say this, you should be very sceptic. But when the people who actually run it in Estonia, this is the response. I asked for feedback, now you cannot really see here. But it said, very forgotten work like a Swiss watch. This was the complete feedback I got from Sven. I asked, can you give me feedback? What should I improve? And what is wrong? What were obstacles and so on? That was the complete feedback. So it's a usable software. And then when you say that something is, you know, you have this zero knowledge proof in the e-voting community, this is sometimes called universal verifiability because this means that anybody can verify that the whole election was tallied correctly, which is of course very important for integrity of the election. But it's one thing to have a theory paper saying this in abstract mathematical language where things are field elements and there may be some arrows and things like that. It's a completely different thing to actually specify how these things are stored on files in different directories and how they are labeled and named and how they are packaged, all of these little elements, okay? So this took a long time to develop this document. I started in 2011 and had a lot of help from Alon and Amnon and their students in the beginning when we run this project in Israel. And now this seems pretty mature. And of course if you want to write a verifier your own, which you should if you are a knowledgeable person in the country, then test vectors become a problem, right? Because for a hash function you can have a test vector, you can print it in a document in a standard and you can check it. But here there are so many parameters that you cannot really do that. So the reference implementation allows you to print test vectors for intermediate results in all of these calculations, okay? And to give you an idea of why that is very nice, I should also say that we have tried this with multiple undergrads. So that's the level of knowledge you need to implement a verifier. Undergraduate in math or computer science or something. Okay, so this is proof of a shuffle. So that's just one of them. And then there is a similar blob for decryption. And all of those are stored in files. So you see the problem here and then you have session identifiers and various padding and stuff like that. You have to say how you derive every little element and how you store it. So it's very hard to get all of those things right in the first attempt. It really takes time for this to mature and you need other people to try it and give feedback and so on. Also, when you apply something like this, you need to have an idea of how long it takes. Is this feasible? Do we need new hardware? Can I run it on the hardware I have and so on? I see it's purpose, there's a benchmarking suite. Okay. And this has been optimized in various ways. Some are perhaps rather obvious, but the first one is what seems to be a novel protocol. I haven't seen it somewhere else, but it's kind of nice that the number of servers doesn't influence the time it takes to decrypt or to verify. So it's very efficient in this way. And there is also a use of rewriting and algebraic tricks to allow more parallelism between the servers because sometimes they wait for each other. The naive description is that they wait for each other. But you want as much as possible of the computations to take breaks simultaneously. Yeah, okay. So what about the source code? Yeah, so this is something that I am very, very concerned about. The way the programming community works today is by patching, patching, patching. And the adversary in my case is other governments, foreign agencies. And we don't want to reduce dependencies as much as possible. We want to achieve something that is nearly stable static code that is not changed. So no patches, you know, two weeks before an election, don't suck in some patch, right? I'm totally aware that this is naive. We're standing on this tower where there are lots of code below us. But at least at this point we can do as well as we can, okay? So minimize this. That's my idea. So I really struggled to not use any scripting languages, not even bash, okay? It might sound crazy, but I think it's actually a sound approach because if you try to do it everywhere, then at least you know that in those few places where it might matter, you didn't do it. You didn't make that mistake. In the same way, comment everything. I really mean everything. Because then you know that you have commented also those places where a comment is needed. Static analysis. I'm sure that you who work in the industry have access to more expensive tools than I have, but this is what I had and I used all the tools I could use. And the union of the complaints is bigger than any one of those. So that's what... And not accept anything, right? Anything that is not, you know, you have to comment every exception. And again, don't believe me, believe Joe Kinnery. He's an expert in this stuff. And he basically gave these things to me as homework. Like, have you done this, Douglas? Have you done this? So I learned a lot by doing this, you know, coming from the theory area. Input and output, the same approach, be very strict with parsing. Like ridiculously strict. Verify the grammar, verify every field with regex and then verify again, you know, with code for every field. Simple data structures. So don't need... So I don't need any parsing, special parsing software because it's very simple, byte-oriented format. Easy to parse. Nobody here could write a parser for that format in like 15 minutes. Okay? And allow different variations by pluggable tools. Okay, so we also need a client. And so my idea was I wanted to have a demo and I didn't really get that far, unfortunately. I wanted a demo voting system, something at least simple that could use the MixNet. But I got stuck because I have very hard time using what was available. So I wrote this from scratch, JavaScript code. And I think the main lesson here is that if you just take... It says hack here, that's a handbook of applied cryptography. If you take the textbook algorithms and you implement those cleanly, you do a little bit of like intermediate level arithmetic algorithms, and then you optimize, then that's good enough. And then you have something that is also like commented with references that you can use for your students when you're teaching this, which I think is also nice. Yeah, and also something that is... I should say here, it says... The next, the last point here, it says that does all the crypto and syronage proofs of knowledge abstractly. This is very important to deal with the absolute nightmare i terms of configuration and software. When you think about multiple ciphertext processed by the MixNet, multiple ciphertext encrypted, and now you want to do syronage proofs for different sizes, are you going to have four loops all over your code, or are you going to collect this? So the right approach here is to basically go back to basic math class and say, I can view this as a product group, I can view Algamal as over a product group, and then syntaktically everything looks beautiful. So if you look at the code, you won't even see that this actually handles much more general notions than simple. So acknowledgments, this is very hard for me to say because I've been doing this on and off, I've done other research for almost 10 years now, and I've talked to many people from different communities to learn and to try out my thinking to get feedback. So these are just the main people, I guess. So in Krypto, it's Johan, and Björn was my former student, he's now at Google in Sweden. Charom was a postdoc, Alon, and Benadida, Olivia Pereira, these are people that I've talked to over the years about crypto stuff. And then for coding, Tobjörn Grandon, who wrote GMP, he is very helpful to make things fast. And Joe Kinnery for code quality, also Kerstin Schürman, Markus Lagergren and Joel Borghen, they wrote the Jrocket JVM, and they studied with me, so it was like I've had really, let's say, from an industry perspective, I think, very cheap, extremely good advice. I could never afford to pay these people for the help that they gave me. And then you need somebody to read all that documentation and try things out. This is really hard to get people to do. That's my experience. So summary, basically what I have tried to do is, starting from my theory bubble, I've tried to look as far out as I possibly can and learn the techniques that I know that some of you are much better at than me and do that correctly by the book. This is the good stuff. And another good thing is that I'm a single author, so if I want to re-factor something, I just take the code and I smash it on the table and put together it in a different way. And I don't have to care about anybody else. This is an advantage. And the bad thing is that we are still, like I said, there are lots of other code floating around in an operating system. There is the JVM and the libraries that I still have to use and so on. So this, I have no control over this. There is this formal verification notion that you can either verify that code behaves correctly at various abstraction levels or you can derive code from type-based languages. So maybe that is the way to go in the future. I don't know. Side channels seem not so relevant in this context due to how these protocols are set up and the fact that they are typically run behind an airwall anyway, the servers. And of course the bad thing is that I'm the single author. So the code is kind of very, very consistent, but probably it has like a dog-less-ish style all over the place. And I'm sure that better programmers can have opinions about some things. I don't know. Okay, so what is the future? The future is if I have the energy or if I have a sponsor or some kind of funding which I lack, is to glue together a complete voting system because I really have all the code that is needed for the client, the authentication. It can be so different in different context that it's not really meaningful to try to implement something on your own. And we already have all these cryptocurrencies, cryptocurrencies. Other possible applications. There was a talk here about messaging. You could ship messages through this thing and it would be verifiable. You could have proofs that things were mixed properly. But mainly what I need, I need sponsors to make it open source because right now I can't really continue doing this on my free time because I don't have real funding to do this. I have small pockets I've received from. And this is a massive project. And it's all online so you can try it out and it's free research. So it's more liberal than open source licenses for researchers, but for real use I have a fair fee. You can look at it if you like. So we have time for one question perhaps. Why don't we go up to the top, yeah. Hi. Thanks for your talk. I was wondering, you mentioned that there's a... Where are you? I'm here. Okay, hey. You mentioned that there is a JavaScript crypto library as part of this project. Yes. It implements a big integer library. Yeah. Is there any sort of formal claim on the functional correctness? Is that formally verified in any way? Formal methods is not my strong side, but the test suite is rather, how should I say, aggressive. So it actually... It compiles, so you can compile it to use different word sizes to find corner cases in the word boundaries, for example. And it does all... I'd be happy to discuss it and explain more. But it's not formally verified, no. Thank you. One more question. Yeah. Hello. I have some questions for the underlying protocol. So what is the verifiable shuffle that you actually end up... Growth shuffle? No. It's the tedious week-stream shuffle. And what's like the asymptotic complexity of that? Or is it linear? Okay. So I hesitate to answer you like this. So on the one hand you can look at that complexity, the theoretical complexity, but on the other hand it's irrelevant for two reasons. Först, the running time of Jens fast, if that is what you think about, the Stephanie Bayer and Jens Groot paper. So the approval of that protocol has about the same theoretical complexity as ours, the prover. The verifier is faster. So this means that at best you can have a factor of two speed up. But do you not care about the communication complexity, is that not that relevant? Running low on time, it sounds like this is going to be a long conversation. Sorry to cut you off. Let's thank him one more time.