 Okay, thank you. I'm going to talk about A40PRNG in a voting system, and this is what I like to call a real-world cryptographic disaster. I'm going to spoil the story, so it didn't ultimately become a disaster, it's just a cryptographic disaster, by which I mean we didn't actually reveal any votes, but all the cryptography failed in a quite spectacular fashion, and at one point it looked like we had put tens of thousands of ballots on the internet in the clear. So I'm just going to make this exciting, and the exciting part is, of course, how does he get out of this one at one point? But it is all going to end well, so there is no reason to have a heart attack underway. Okay, so let me just say what we're all on about. We're on about internet voting. This is voting from home. A voter gives his computer his vote, the computer encrypts it, passes it through the internet. The encrypted vote arrives at some infrastructure, lots of stuff happens. Typically there are lots more arrows when you look at the full protocol, but this is the basic idea, and eventually a result comes out. Now, of course, voting is, as we may have noticed over the past couple of years, voting is an interesting attack target, and internet voting has lots of attack surfaces. You have the internet, first of all, very, well, a bad place. The voter's computer, a very bad place, and if you've been looking at who these voters have been elected, I'm not going to trust them either. So, I mean, there's lots of bad things. If you're in the US, you don't trust the infrastructure. In Norway, we trust the government. I like to use the phrase, we trust the government not to intentionally screw up, which, yeah, and of course, one of the really interesting things with voting, especially voting from home, it doesn't really matter if it's via the internet or if you're writing ballots and putting them in the mail, coercion. Someone's helping you vote. And this is a real thing. People are willing to help other people vote. And somehow, sometimes, people aren't so happy after they've been helped. So, this is a very difficult problem. And one of the things that makes it so difficult is that as a system designer, you have to defend against all these attacks. The attacker, he chooses how he wants to attack you. So, if you have many different attacks, and as we all know, when you try to defend against one thing, you open up for the other, which means that voting systems, they tend to include lots of moving parts, lots of nice cryptography. So, it's really interesting. Now, we need to think about context because voting happens not in a conference like this with a nice presentation on the on it. It really involves people, politicians. And, I mean, in Norway, we wanted to do internet voting, but a lot of people didn't want to do it. Typically, they're very worried about coercion, and they have very good reasons to be worried. They see this as a real thing. Unlike here in Switzerland, where by definition coercion doesn't happen, they have lots of vote by mail. Okay. So, we see this really interesting thing in parliament. There's a big debate. Everyone's against voting, internet voting. And then, through the magic of democracy, when they come to the vote, there's a majority for voting. I like that because then my cryptography was deployed, which is kind of nice. Now, in 2011, we deployed something. It all worked. Everything was nice. But still, there's this big political controversy, which means that politicians, what do they do when there's some controversy? Well, they say, oh, do we have to decide now? Do we have to decide now? Can we delay it a bit? And of course, it gets delayed, which means you can't start preparing until the politicians have actually decided to do this stuff. So, and what do you care about the delay? We had a system. It ran in 2011. It worked well. Well, you always want to improve your system. So, in 2011, we used one cryptographic protocol, and I really wanted to improve it. I'd written the first protocol or most of the protocol very, very quickly. So, it wasn't really elegant. The security proof was even less elegant. Yeah, we want to improve it. In 2011, we used all the cryptography happened in the small Java applet. Anyone remember those? Anyone remember how much of a pain Java in the browser was? Yeah. So, we wanted to get rid of that, which meant we're going to do cryptography in JavaScript. Okay. So, we're replacing one form of pain with a different form of pain. But cryptography, even back in 2011, 2012, JavaScript was improving. I mean, it's much better today. But even then, JavaScript was, it wasn't the pain that it was in, say, 2005 when it was completely hopeless. And another thing that, you know, e-voting, we all care about verifiability. You really want to check that your vote was counted. So, there were lots of stuff we wanted to do. And there wasn't a lot of time. So, we got what we call a rush job. Okay. And we all know you shouldn't do that. So, okay. Now I want to show you just a part of the protocol that we really need to know about. And it's really simple what we need to know about to explain what happened. And that's quite simple. The voter tells the computer what to vote. The computer encrypts the ballot and this is fairly simple encryption. Algomile plus some added stuff. The ciphertext goes to the infrastructure. Something happens. Lots of stuff happens, which is not on this figure. And then one of the things that happens is because we want this verifiability, the hashes of the ciphertext is put on the Internet. This kind of commits the infrastructure to include this ciphertext in the count, which means it can't discard your ballot if it feels like it. So, this improves verifiability. Voters are actually able to check that their ballot was included in the count. And this is a good thing. I have no idea if anyone actually did check. But it's minority interest, this verifiability thing. Now, today randomness in JavaScript is completely solved. There's standard APIs. You can do this by calling what is called get random values or whatever. Back in 2011, 2012, yes, this API had appeared, but support wasn't uniform over all browsers. So, essentially, yes, it was a solved problem, but it was a bit inconvenient. So, what do you do? Well, you build your own pseudorandom later. But you build it in such a way that you take randomness from known sources that are known to be good, and then you just run AES encounter mode to get randomness. So, our vendor, and I would very much like to say that I designed most of the cryptography, but I did not write a single line of code. Not my fault. But our vendor then did this perfectly reasonable function. So, you start by making sure when you want to generate some randomness that you actually have some key material to generate from. Then you run AES encounter mode. And if you generate a lot of randomness, well, then you rekey underway. I mean, this is a completely standard thing. And then when you're done, what you do is you rekey again, right? And now, some of you should have been laughing because you have now seen the bug. But as you notice, the bug isn't that easy to see except when you notice its effects. But anyway, the bug was noticed not because of code inspection, but because of its effects which I'm going to go back to. But the effect of this bug, I'm deliberately not telling you because it's kind of nice to feel that you don't see it, but it's there. The point of this bug is that this generator that was implemented, it will give you one random number, and afterwards it's going to give you fixed random numbers every time. Okay? So you get one random number, and then you get fixed random numbers that are fixed for everyone. Same random number, no matter what. First time you call it random number, then fixed random numbers. That's the important thing. It is, and then we go back to look at this, and I said the encryption of the ballot, that's a straight Elgamal encryption. Elgamal requires one random number, so we're okay. The encryption is nice. It works. Okay. Then we can go home. Unfortunately not, because as I said, we have to defend against lots of things in voting, and one of the things we need to defend against is someone, for instance, just copying someone else's encryption and resubmitting it. There are lots of really clever attacks that you can do with this that show up in real voting systems. So we have to defend against it, and how do we defend against that? We have a snor proof that proves essentially that you know the randomness used in the first used in the Elgamal encryption. Now, those of you who know snor proofs, you know that snor proof ends up with a linear relation between the randomness you want to prove you know, and the randomness used in the snor proof. So the snor proof is using some randomness, and our random generator, it gives you a fixed value, it gives you four, and it gives you a linear relation between the randomness that isn't random and the randomness that you want to prove you know, which means our snor proof is basically telling us the randomness of the encryption, which means the snor proof, which is there to defend it now because of this random number generator breaking open the encryption instead. As an unintended consequence, who knew the random number generator would be destroyed. But this is okay, we can defend against it, the cryptography has failed completely, but remember this server is not on the internet, well it is on the internet, but it's well defended, you can put a guard at the door, you can do blah, blah, blah, blah. So this is okay, there's this TLS channel that everything is inside, so it's okay. But then comes the real kicker, and that means when doing the El Gamal encryption, the encryption code sometimes discarded the first random number, which means that the encryptions, about half of them are encrypted using a fixed random number. And that's bad, but what's worse is when you realize we're putting hashes of these ciphertexts on the internet, and the only thing that's random is, or that's unknown, is the voter and his vote, which is easy to guess. So at one point it looked like anyone could go on the internet, guess a voter and his vote, and check if the guess was correct. That's putting tens of thousands of votes in the clear on the internet. Fortunately, and this is a bit embarrassing, this didn't happen, why? Because somehow our vendor hadn't actually implemented it as I thought they would. There's an authentication token lying around, and they included it in the hash. I think that's called luck. Okay, but anyway. So the protocol is probably secure, the implementation, well, no. Take your time when you implement crypto. You really need some time to do this. In 2011, we had more time, things happened that would have discovered this bug. In 2013, we didn't have time. The really interesting thing is that nobody cares, except for people in this room. Nobody cares. There was no press, no, well, we told everyone this bad thing happened. No newspaper reported it. No one cares. There was one quibble about the headline of the press release saying that we nearly lost everything. That was it. No one cares. So when the government says no more internet voting, this is not why it's a coercion, not this. No one cares. And we've since used internet voting many times. Thank you. We have time for one quick question. Well, you're saying people are not bothered or I can take one example of India where there is not internet voting, but EVM, electronic voting machine. So do you see such scenarios exist even with EVM, which are not connected on internet? If this bug had happened in an increasing voting system, a voting machine, it would have had more or less the same consequences. If you had verifiability, things could have flown out onto the internet in the same way. So is there an impact on the votes that are stored on the machine? Likely impact? This thing only impacted confidentiality. It did not impact integrity. Integrity of the election was never in doubt, but confidentiality, and as we all know, if you cannot guarantee confidentiality, you don't have integrity either. But when an accident impacts confidentiality, that might not be so serious for integrity. Thank you. Okay, let's thank Speaker again.