How to vote verifiably in 2014 Talk by Vanessa Teague, University of Melbourne [email protected] 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 Im not representing the VECs 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? Whats wrong with this picture? Voters

PCs Encrypted votes Election outc RSA RSA RSA Electoral Commission

with decryption key The main idea This talk is about how to adapt a verifiable cryptographic voting system called Prt Voter to Victorian State Elections. Its 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 dont 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 Doesnt reveal how they voted All the receipts (i.e. encrypted votes) are published The voter or a proxy can check that its properly included in the count Anyone can check that the set of cast votes is properly shuffled & decrypted While privacy is preserved

The requirements Lets 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 Prt 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 dont use that ballot Then vote on an unchallenged one So you cant 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 doesnt reveal the vote Red Green 5 1 Chequered 3

Fuzzy 2 Cross $rJ9*mn4R&8 $rJ9*mn4R&8 4 Talk outline Voting

Checking from home that your vote is there Verifying shuffling and decryption Privacy Checking from home that your vote is there Theres a public website listing all the receipts More precisely, theres 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 voters 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 Whats 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 Receiver Sender

RSA 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 cant be linked to the old one Randomised partial checking

By Jakobsson, Juels & Rivest Significant improvements by Wikstrm We cant (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 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 dont tell your computer how you voted e.g. the plain version of prt 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 30candidate STV vote Summary This provides a rigorous after-the-fact argument that

the answer was right (with high probability) To the court wed 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 https://www.usenix.org/system/files/ conference/evtwote12/evtwote12-final9_0.pdf http:// www.computing.surrey.ac.uk/personal/st/S.Sc hneider/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 youd like to write your own proof checker, verifier, signature checker, etc, please come and talk to me, If you think youve found a bug, please come and talk to me, If you read the supporting materials and you think youve found a bug, please come and talk to me. Questions?