1. A (Brief) Comparison of Cryptographic Schemes for Electronic Voting
Tartu, Estonia May 17, 2004
Berry Schoenmakers
Technical University of Eindhoven
The Netherlands

2. Personal Experiences Cryptography, since 1993 (CWI, DigiCash, TUE)
Privacy-protecting electronic payment systems
e.g., eCash system at DigiCash (Chaum’s blind signatures)
Electronic voting schemes
since 1994
homomorphic approach
‘shadow election’ May 1998 during Dutch national elections
technical advisor of VoteHere
EU project CyberVote (Sept – March 2003)
consultancy for the Dutch government
KOA-initiative (“Kiezen Op Afstand”)
upcoming experiment for ex-patriots (by touch-phone and internet)
(Next “wave:” other practical two/multiparty computations, e.g. millionaires, private matching, secure auctions, …)

4. Paper-based elections
Advantages:
Easy to understand.
Transparent: in principle, observers may monitor the process for correct execution.
Disadvantage:
Requires physical presence of voters, talliers, observers
Fundamental properties:
Security: election result must be verifiably correct
Privacy: individual votes must remain secret

5. Electronic elections Solve security and privacy issues:
By trust?
By legal measures?
By technology? Yes, using cryptography!
Cryptographic approaches to electronic elections have been studied since the early 80s.
Electronic elections form a primary example of a secure multiparty computation.

6. “Trusted party scenario”
Voting:
1. Voter connects to voting server through an SSL connection (as with “secure web servers”)
2. Voter authenticates himself/herself
3. Voter casts a vote
Tallying:
Server (trusted party) sums all the votes and announces the election result

7. Problem: level of trust in insiders
Attackers
Outsiders, i.e., anyone on the Internet:
May try to attack the SSL connection or the server.
Relatively easy to counter
Insiders, i.e., those who run the election:
May try to alter the election result
May try to learn people’s votes
Much harder to counter
"Those who cast the votes decide nothing Those who count the votes decide everything." Josef Stalin

8. Bulletin board model Sub-tally 1 Sub-tally 2 …………. Registered voters
Alice
signed
Tallier #1
Sub-tally 1
signed
Bob
signed
Carol
signed
Tallier #2
Sub-tally 2
signed
Diane
signed
………….
Registered
voters
Registered talliers
Sub-tally 10
signed
Tallier #10
………….
Scrutineers/observers
(or, just anybody)

9. Election Roles Election Officials Voters
select a PKI (“one (wo)man, one key pair”) for authentication of voters, talliers and officials
run the Bulletin Board server(s)
assumption: access to Bulletin Board is not anonymous
Voters
large-scale elections
many voters, “vote&go”
Talliers (possibly incl. MIXers)
scalable distributed trust
possibly a large number of talliers, e.g. 100 talliers
Scrutineers (or, observers, auditors)
can be anyone: universal verifiability

10. Bulletin Board = server network
Properties (public broadcast channel):
Anyone can read BB
Nobody can erase anything from BB
Voters, talliers, officials write ballots to their own sections, signed with their public keys
BB produces signed receipts (threshold signature)
Implemented as a kind of Byzantine agreement
Replicated design prevents denial-of-service by BB
if < 1/3 of the BB servers is malicious, then BB is reliable
e.g., Rampart toolkit (Mike Reiter)

11. Requirements for voting systems
Only registered voters may vote
Each voter may vote only once
Ballot secrecy (privacy)
Public verifiability of election result
Robustness
No interaction between voters
No vote duplication (copying someone’s encrypted vote without knowing the vote)

12. Authentication vs. encryption
Separate voter authentication from vote encryption:
makes it easy to exclude double voting
Voter authentication
Ranging from weak to strong:
UserID/password
Challenge/response, possibly using hardware tokens (e.g., as used for Internet banking access control, ChipKnip)
Digital signatures, PKI
Vote encryption
Special protocols

13. Hard nut to crack Privacy and verifiability at the same time
Ballot Secrecy: even when the system is fully audited, all individual votes should remain private
Public Verifiability: anyone (incl. observers, auditors) is able to verify the integrity of the election result against the encrypted votes cast by legitimate voters

14. Modern cryptography
Achieving privacy and verifiable security at the same time
cannot be solved using conventional (public key) encryption and authentication techniques only.
but requires advanced techniques such as:
zero-knowledge proofs of knowledge
verifiable secret sharing
homomorphic encryption
threshold decryption

15. Universally verifiable voting
Homomorphic schemes:
Benaloh et al. mid 80s
Sako-Kilian 1994
Cramer-Franklin-Schoenmakers-Yung 1996, Cramer-Gennaro-Schoenmakers 1997
First practical homomorphic encryption protocols
Damgård-Jurik (using Paillier cryptosystem)
Verifiable MIXes
Sako-Kilian 1996
Neff 2000
First practical publicly verifiable mix protocol
Furukawa-Sako 2001
Groth 2003
Important innovation: efficient zero-knowledge proofs

16. Verifiable black box E1 = Ballot Alice Black Box Counting Process
using private keys
of talliers
E1 = Ballot Alice
E2 = Ballot Bob
T = Final Tally
Aux = Sub-tallies
E3 = Ballot Carol
Em = Ballot Diane
Verify (E1,…,Em, T, Aux, public keys of talliers) = accept or reject

17. Some intuition: secret sharing
Single tallier sees everything:
Random split between two talliers:

18. ElGamal encryption (a, b) m m uses uses Receiver’s private key: x
Receiver’s public key: h = gx
Sender encrypts plaintext m:
(a, b) = (gw, hw m),
using a random w
Receiver decrypts ciphertext (a, b):
b / ax = m
(a, b)
Receiver m m
Sender
ciphertext
plaintext
plaintext h x
uses
uses

19. Homomorphic ElGamal encryption
Consider a vote v Î {1,0} @ {yes,no}
Ballot is ElGamal encryption of vote gv:
(a, b) = (gw, hw gv),
Homomorphic property:
(a, b) * (a', b') = ( gw+w', hw+w' gv+v' )
Tallying: decrypt product of all ElGamal encryptions to find sum of votes.

20. Use of zeroknowledge proofs
Question: How to prevent voters from sending in ballots like these?
(a, b) = (gw, hw g2) double yes
(a, b) = (gw, hw g-4) times yes
(a, b) = (gw, hw g1000) times yes
Answer: use zero-knowledge proofs to prove that each ElGamal encryption contains either g0 or g1 without revealing any additional information.

21. Homomorphic approach Each voter Vi post an ElGamal encryption:
(ai, bi) = (gwi, hwi gvi) plus a zero-knowledge proof that vi=0 or vi=1
Compute (Pi ai , Pi bi) = (gW, hW gT) with W = Si wi and T = Si vi
Talliers threshold-decrypt (gW, hW gT) to get gT and finally T

22. Verifiable MIXes ….. encrypt using talliers' public key
SSL/WTLS channels
(authenticated)
vote1
Voter
Attacker
vote1
vote2
vote3
vote3
vote2
vote3
…..
vote2
vote2
vote2
Voter
Voter
vote3
vote1
vote1
vote1
Vote server
(aka "bulletin board")
MIX server
MIX server
Talliers
Each MIX server takes the votes on the bulletin board, transforms and changes their order and puts them back on the board.
This type of provable MIX based solutions has been proposed by Masayuki Abe and Markus Jakobsson.
An alternative way is to use traditional MIXes
First the voter obtains anonymous authorization from the vote server using blind signatures
Then the voter sends his vote and the authorization to the tallier via a MIX network. In order to do this, the voter has to decide the sequence of MIXes to use, and repeatedly encrypt the message with the public key of each MIX in the sequence.
This is essentially the scheme that the iSOCO internet voting expert (Andreu Ribera Jorba) uses in his thesis. The drawbacks are:
blind signatures are expensive
mobile node has to perform many encryptions; security can be increased by increasing the number of MIXes, but this also increases the load on the mobile node. In the provable MIX approach shown in the slide, the mobile node performs only one encryption and one standard signature. The rest of the work is done by the servers.
result
Voter
vote3
encrypt using talliers' public key
(Modified El Gamal encryption)
transform and permute
decrypt

23. Cryptographic techniques
Blinding of ElGamal encryptions:
Input: (a, b) = (g w, h w m)
Output: (a', b') = (a, b)*(g r, h r) = (g w+r, h w+r m) where r is random
plus a zero-knowledge proof of correctness
Verifiable MIX, e.g. 2 x 2 MIX: E1
Secret, random π,
secret blinding
E'π(1) E2
E'π(2)
plus a ZK proof

24. Performance: Work per player
Counting modular exponentiations
m voters, n talliers, m >> n
Complexity of zero-knowledge proof: f
Homomorphic
Verifiable MIX
Voter
O(f)
O(1) BB
O(mf)
O(mn)
Tallier
O(m)
MIXer
n.a.
O(m), sequential
Scrutineer

25. Solution = Protocol + Infrastructure
Voting protocol: cryptographic core of the system, protects even against insiders (who run the system)
Security infrastructure: required to stop a multitude of attacks, related to e.g.:
Security of client and server computers
Security of (voting) application software
Security of communication between these computers
…………….
Shortcomings of the cryptographic protocol cannot be remedied by strengthening the security infrastructure

26. Author’s address Berry Schoenmakers berry@win.tue.nl
Coding and Crypto group
Dept. of Math. and CS
Eindhoven University of Technology
P.O. Box 513
5600 MB Eindhoven
Netherlands