Talk by Vanessa Teague, University of Melbourne
vjteague@unimelb.edu.au
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?
Voters
PCs
Encrypted votes
Election outco
RSA
RSA
RSA
Electoral Commission se
with decryption key
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
Red
Green
 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
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
Red
5
Green
1
Chequered
3
Fuzzy
2
Cross
4
$rJ9*mn4R&8
$rJ9*mn4R&8
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
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 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
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 30candidate 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
 https://www.usenix.org/system/files/conference/evtw
ote12/evtwote12-final9_0.pdf
 http://www.computing.surrey.ac.uk/personal/st/S.Sch
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?