Talk by Vanessa Teague, University of Melbourne Joint work with Chris Culnane, James Heather & Steve Schneider at University of Surrey, Peter Y A Ryan at University of Luxembourg, Craig Burton at the Victorian Electoral Commission, and many helpful others

Disclaimer This is a technical talk about our proposed design, with the aim of getting other researchers interested in it and perhaps in doing some analysis, verification, or improving I’m not representing the VEC’s official position on anything. Though at the moment my understanding is that they intend to use this system in the 2014 state election for specific classes of voters who would otherwise need assistance to vote

Why verifiable voting? What’s wrong with this picture? Electoral Commission server with decryption key Voters PCsEncrypted votes Election outcome RSA

The main idea This talk is about how to adapt a verifiable cryptographic voting system called Prêt à Voter to Victorian State Elections. It’s an attendance system designed for privacy and verifiability

The challenge Vote privacy is relatively easy Using standard crypto and a completely trusted decryption & counting system Verifiability is relatively easy If you don’t care about privacy: just make all the votes public The challenge is to do both: verifiably accurate results that preserve privacy Verify the election not the system!

Voter-verifiability overview Each voter can check that their vote is recorded as they intended Using a polling-place protocol described here The voter leaves the polling place with an encrypted receipt Encodes their vote Doesn’t reveal how they voted All the receipts (i.e. encrypted votes) are published The voter or a proxy can check that it’s properly included in the count Anyone can check that the set of cast votes is properly shuffled & decrypted While privacy is preserved

The requirements Let’s demonstrate that the system does the right thing, even if some of the computers are compromised This is how ordinary paper-based elections work At least most of the time Other requirements like usability, robustness, security from outside attack, etc are also important But not part of this talk

Talk outline Voting Checking from home that your vote is there Verifying shuffling and decryption Privacy

Prêt à Voter Uses pre-prepared paper ballot forms that encode the vote in familiar form. The candidate list is randomised for each ballot form. Information defining the candidate list is encrypted in an “onion” value printed on each ballot form. Actually, we print a serial number that points to the encrypted values in a public table Red Green Chequered Fuzzy Cross $rJ9*mn4R&8

Ballot auditing Each voter can challenge as many ballots as they like And get a proof that the onion matches the candidate list Then don’t use that ballot Then vote on an unchallenged one So you can’t prove how you voted Red Green Chequered Fuzzy Cross $rJ9*mn4R&8

Voting Fill in the boxes as usual Use a computer to help Check its printout Against candidate list Shred candidate list Computer uploads vote Same info as on printout Take printout home It doesn’t reveal the vote $rJ9*mn4R&8 Red Green Chequered Fuzzy Cross $rJ9*mn4R&

Talk outline Voting Checking from home that your vote is there Verifying shuffling and decryption Privacy

Checking from home that your vote is there There’s a public website listing all the receipts More precisely, there’s a “bulletin board” which is a public website augmented with some evidence that everyone sees the same data Find yours

Talk outline Voting Checking from home that your vote is there Verifying shuffling and decryption First some background on public key crypto Randomised partial checking Privacy

Verifying shuffling and decryption Now we have a list of encrypted votes On a public website Encrypted, and linked to voter’s identities Because each voter still holds their receipt We want to Shuffle the votes To break the link with voter ID Decrypt the votes Prove that this was done correctly

What’s public-key cryptography? The receiver generates two keys: a public key e (for encrypting), and a private key d (for decrypting) She publicises the public key e People use this for encrypting messages They also include some randomness She keeps the private key d secret She uses this for decrypting messages

Picture of public-key cryptography Sender Receiver RSA

Re-randomising encryption Without knowing the secret key, re-do the randomness used in the encryption The message stays the same But the new encryption can’t be linked to the old one

Randomised partial checking By Jakobsson, Juels & Rivest Significant improvements by Wikström We can’t (completely) prevent a hacker from breaking in to all the computers and changing the votes, but We can check the process thoroughly enough to be confident that If the checks succeed then The system produced the right output With very high probability

Randomised partial checking A pair of mix servers shuffle and rerandomise Choose randomly to prove the link to start or end

Provable decryption step Trust me, this can be done Using chaum-pedersen proofs of dlog equality Showing proper decryption of El Gamal ciphertext given El Gamal public key

Talk outline Voting Checking from home that your vote is there Verifying shuffling and decryption Privacy

Whenever you have a computer helping you fill in your vote, that computer is a privacy risk So is the ballot printer There are some clever schemes for verifiable voting that don’t tell your computer how you voted e.g. the “plain” version of prêt à voter in which you fill in the ballot with a pencil But none of them work with 30-candidate STV This scheme does about the best I can imagine at preserving privacy while providing a usable 30- candidate STV vote

Summary This provides a rigorous after-the-fact argument that the answer was right (with high probability) To the court we’d say We worked really hard to make sure the software was correct We worked really hard to make the computers secure But even if these were not perfect: The voters & the public could check the integrity of the data directly And the scrutineers can reconcile that with the rest of the count And would have detected a manipulation with high probability

Further info ote12/evtwote12-final9_0.pdf neider/papers/2013/SDSTechReport.pdf neider/papers/2013/SDSTechReport.pdf Though both are a bit out of date – if you want to read an up-to-date design doc with care then wait a few weeks for an updated TR

Conclusion and questions If you’d like to write your own proof checker, verifier, signature checker, etc, please come and talk to me, If you think you’ve found a bug, please come and talk to me, If you read the supporting materials and you think you’ve found a bug, please come and talk to me. Questions?