CRYPTOGRAPHIC PROTOCOLS:REVOCABLE ANONYMITY AND E-VOTING

By

BEKIR ARSLAN

A PROPOSAL PRESENTED TO THE GRADUATE SCHOOLOF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT

OF THE REQUIREMENTS FOR THE DEGREE OFPHD

UNIVERSITY OF FLORIDA

2009

1

TABLE OF CONTENTS

page

LIST OF TABLES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

LIST OF FIGURES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1 INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 REVOCABLE ANONYMITY . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2 Problem Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.3 Building Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3.1 Cryptographic Hash Functions . . . . . . . . . . . . . . . . . . . . . 82.3.2 Symmetric Encryption . . . . . . . . . . . . . . . . . . . . . . . . . 82.3.3 Asymmetric encryption and signatures . . . . . . . . . . . . . . . . 82.3.4 blind signatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.3.5 secret sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.4 Previous Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.5 Proposed Protocol Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.5.1 Participants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.5.2 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.5.3 The protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.5.4 Security Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.5.5 Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.6 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3 ELECTRONIC VOTING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.2 System Design Perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.3 Voting System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 163.4 Building Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.4.1 Paillier Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.4.2 Proofs of Knowledge (Zero-Knowledge) . . . . . . . . . . . . . . . . 173.4.3 Threshold [Homomorphic] Encryption Schemes . . . . . . . . . . . . 17

3.5 Previous Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.5.1 Standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.5.2 Major Issues with the Standard System . . . . . . . . . . . . . . . . 183.5.3 Pret-a-Voter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.5.3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 203.5.3.2 Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.5.4 Homomorphic Encryption Based Protocols . . . . . . . . . . . . . . 213.5.5 Possible Reasons for not adobting advanced cryptographic schemes . 22

3.6 Protocol 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.6.1 Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2

3.6.2 Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.6.3 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.7 Protocol 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.7.1 Protocol Specification . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.7.1.1 Participants . . . . . . . . . . . . . . . . . . . . . . . . . . 253.7.1.2 Voting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.7.1.3 Tallying . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.7.2 Write-In Ballot Overview . . . . . . . . . . . . . . . . . . . . . . . . 273.7.2.1 Vector Ballots . . . . . . . . . . . . . . . . . . . . . . . . . 273.7.2.2 Pre-Listed Candidates . . . . . . . . . . . . . . . . . . . . 28

3.7.3 Write-in Ballot Details . . . . . . . . . . . . . . . . . . . . . . . . . 283.7.3.1 Construction . . . . . . . . . . . . . . . . . . . . . . . . . 303.7.3.2 Opening Ballots . . . . . . . . . . . . . . . . . . . . . . . . 313.7.3.3 Auditing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.7.3.4 Proofs of Knowledge . . . . . . . . . . . . . . . . . . . . . 32

3.7.4 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.7.4.1 Receipt-Freeness . . . . . . . . . . . . . . . . . . . . . . . 323.7.4.2 Vote cast as intended . . . . . . . . . . . . . . . . . . . . . 323.7.4.3 Authority-Voting Device Collision . . . . . . . . . . . . . . 333.7.4.4 Coercer-Voting Device Collision . . . . . . . . . . . . . . . 333.7.4.5 Denial of Service Attacks . . . . . . . . . . . . . . . . . . . 333.7.4.6 Election procedures to improve security . . . . . . . . . . . 33

3.7.5 Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.7.5.1 Comparison with Pret-a-Voter . . . . . . . . . . . . . . . . 343.7.5.2 Comparison with Standard . . . . . . . . . . . . . . . . . . 34

3.8 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4 SCHEDULE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3

LIST OF TABLES

Table page

4

LIST OF FIGURES

Figure page

3-1 sample write-in ballot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5

CHAPTER 1INTRODUCTION

Cryptography is the science of analyzing and deciphering codes and their applications.

Encryption and Decryption are the two obvious parts of this science. However there

is much more to cryptography. Cryptographic protocols are protocols which take the

basic tools of cryptography - like encrpytion/decryption or digital signatures - and apply

them to various complicated problems. There are many applications, from secure online

payments, to secure multiparty computation, from electronic cash to secure key exchanges.

In this thesis, we are interested in two specific applications. The first part tackles

a problem related to anonymity. We are interested in designing a message board-like

application that requires authentication, yet supports anonymity when sending messages.

The second part will be about electronic voting. The main issue is the ability to

receive a receipt demonstrating that the vote is correctly counted - without explicitly

giving a proof of vote that might be used for vote buying or coercion. The focus is on

applying the ideas on DRE (Direct Recording Electronic) voting machines, systems that

are in practical use today.

6

CHAPTER 2REVOCABLE ANONYMITY

2.1 Introduction

Anonymity, along with privacy, authenticity and security are the main concerns of

cryptography. Several problems requires methods supplying anonymity, and it is the key

issue for some problems in the field e.g. e-cash and e-voting. Several general purpose

networks like Anonymizer[1] or Tor[2], or more specific anonymous networks (like the P2P

network FreeNode) have been designed over the years, and their popular use underlies the

need for anonymity in todays world.

Altough these networks are technically sound, there are some cases where they are

not prefarable. One example is that sometimes it is prefarable not to have complete

anonymity, usually to prevent users from breaking the rules or being able to stop criminals

using these networks for their crimes. A well known example for such a problem is e-cash,

where money laundering and blackmail is a serious problem that cannot be solved with

complete anonymous networks. These issues caused researchers to develop revocable

anonymity, where authorities have the power to identify users participating in the protocol

if the need arises.

Even though that is usually a sufficient solution when there is one authority (like a

judge in real life), who should have the power to decide if anonymity should be revoked

for a user, in some applications giving this much power to a single entity is not ideal. Our

proposed protocol is a practical solution for those applications. It distributes the power

to revoke to several authorities, making it necessary that at least some of them agree of

the necessity for revokation. Furthermore, it assigns pseudonyms to users, which makes it

possible to have a distinct presence in the network, so that messages from the same user

can be verified to be so. Another advantage to the use of pseudonyms for the registrars

is the possibility to see all the messages that a speicific user sent, which can be used to

decide if revocation is indeed necessary.

7

2.2 Problem Definition

The problem we are addressing can be specified in general terms as designing a

protocol that simulates a message board satisfying the following requirements:

1. Posting to the board requires registering a pseudonym and an asymmetric key pairassociated with it. However the registrar should not know the link between the usersand pseudonyms. Registration will require authentication, but the extend to this willdepend on the application. It can vary from real word authentication like driverslicense ID or social security number, to just the IP address of the user.

2. The user can post several messages using the same psudonym. Since these messageswill need to be signed, no user will be able send a message using a fake pseudonym.

3. If k out of n registrars cooperate, the link between the pseudonym and the usercan be identified. Since all messages are signed by a key associated with a specificpseudonym, all the messages from that particular user will be known.

2.3 Building Blocks

2.3.1 Cryptographic Hash Functions

These are similar to the hash functions used in computing, functions that map large

chunks of texts into smaller texts or integers. They usually are required to be easy to

calculate and uniform. Cryptographic hash functions on the other hand, also require some

additional properties, making construction of text very difficult (or impossible) from the

hash and having even a small change in the text change the hash value, are the more

important ones.

2.3.2 Symmetric Encryption

An encryption algorithm is considered symmetric, if the same single key is used for

both encrypting the plaintext and decrypting the ciphertext. Historical algorithms are all

symmetric, and it is still widely used because of the speed of modern algorithms. Block

ciphers and stream ciphers are the common generic methods currently used.

2.3.3 Asymmetric encryption and signatures

The problem with symmetric encryption is the need for both the sender and the

receiver to agree on a key beforehand. In most cases that is not a problem, but in a lot

8

of cases - especially with the advance of the Internet it is not sufficient. Asymmetric

encryption is a solution to this problem: The key that is used for encryption and the key

that is used for decrypting are different. So there are two keys, usually one public and one

private, so that someone who knows your public key can send you a ciphertext that only

you (using your private key) can decrypt.

In some asymmetric encryption algorithms, it is also possible to use the private key to

encrypt and the public key to decrypt. These algorithms are especially useful for signing

messages. One can encrypt the message with his public key and the receiver can verify the

authenticity of the message by decrypting the attached ciphertext using the senders public

key, and comparing it to the plaintext. Usually, to improve performance, one encrypts a

hash of the message, which for this purpose works as well as the whole message.

2.3.4 blind signatures

Although cryptographic signatures are used extensively in many protocols, in many

cases there is a need for a signature way to sign a message without actually being able to

read it. One obvious use for these schemes would be to use them for notarary purposes - if

the signed document is valuable. Another would be to use them in time-stamp protocols.

One key problem where blind signatures were fundamental in their solution is e-cash.

The ability to getting e-cash from authorities, but wihout actually making it traceble is a

problem where blind signatures were successfully applied.

2.3.5 secret sharing

Secret sharing is a protocol where a secret (usually just a key) is shared among many

players. The key can only be constructed when all players agree. To prevent various

problems, these are usually designed so that k out of n of the players (k ¡ n) are sufficient

to reconstruct the secret. Recently some new protocols are published where there is not

even a need for a central authority to distribute the shares of the key.

9

2.4 Previous Work

In the cryptographic protocols area, there are several research problems which are

very similar to this problem. Electronic Voting - to some extend - shares some similarities

to this problem, as it also requires authentication and anonymity. However e-cash is

probably the most similar, as unlike voting, the protocol is not used just for one message.

The major difference between both of these problems and the problem at hand is the

need to eliminate duplicats - that is in our problem it is permissable to send several

messages after one registration. Another difference is the use of pseudonyms, which is not

used in e-cash protocols - as it would link transactions and thereby reducing anonymity

and privacy. As noted before, the e-cash literature has many ideas which might be a

good starting point for this protocol. The main reason for this is (other than the general

similarity of the problems) that in recent years much research has been done to prevent

the use of e-cash for criminal activities like money laundering. This has resulted in many

protocols where the anonymity can be compromised if authorities see a criminal activity.

The most common principle in these protocols is the use of fair blind signatures.

There are several schemes which employ revocable anonymity schemes in the context

of e-cash [24][17][8]. The differences between these protocols are usually in how much

the authorities/trustees are seperated from the e-cash issuer banks and also in some

efficiency and defenses to some esoteric attacks against the systems. Preventing criminals

to use e-cash systems for their own purposes was the key reason these protocols were not

considered practical. In 1995, Stadler et al. proposed a variation on blind signatures,

called fair blind signatures, specifically for this problem [37]. In [8], an e-cash system is

designed where the anonymity can be revoked by third party trustees to prevent criminals

using anonymity for their own purposes. The difference from previous work is that it does

not use an inefficient cut-and-paste scheme and does not necessitate the trustees to be

part of the authorization process. In [24] the authors propose a protocol which also guards

against possible attacks like coercion of cash issuing banks. Although these protocols can

10

possibly be modified to be used for our purposes, the need for minimal involvement of

the authorities on each transaction and the requirement of k out of n security turn out to

be serious problems. Another important problem would be - similar to the problem with

general purpose anonymizers - the case that messages cannot be linked to the same user

without revocation, which is a requirement in our model.

There are also some general schemes for controlled anonymity. Claessens et al.

have several publications [12] about this problem as part of the “APES: Anonymity and

Privacy in Electronic Services” workgroup in the Katholieke Universiteit Leuven, Belgium.

Both their work and [38] have as a purpose the design of general methods for controlling

anonymity - usually build on top of a general purpose anonymous communication system

(like DC-nets and probably TOR as well). But since this service is based on a general

purpose anonymous network, applying it to our problem would be difficult. One reason is

the assumption of an anonymous network where the protocol can operate. Another point

is the need to combine the judge, the law enforcement agency and the authorities into

one without jeopardizing anonymity - as these are all different entities in these networks.

But the most serious problem is that a protocol constructed this way can only identify

the sender for each message seperately, and there is no easy way to find all messages sent

by the same user (without opening them all), or deducing if two messages are sent by the

same sender without opening them. In other words, pseudonyms are not used, and each

message has in effect a distinct random pseudonym.

2.5 Proposed Protocol Outline

The protocol is based on the fair blind signature protocol using cut-and-choose

proposed in [37]. Before the registration phase, the registrars will have obtained a shared

key to be used in case revokation is required. During the registration phase, the user

registers a pseudonym and an associated public key, which the signer will not be able to

see and therefore will not be able to link afterwards to the user. After the registration, the

11

user will be able to submit messages using the pseudonym and adding a signature, which

can be verified with the associated public key.

2.5.1 Participants

• The user U, who is trying to register a pseudonym p and its associated public keyPKp.

• The n registrars Ri, who will have the power to trace the user of any message, whenk of them agree. The registrars will only be part of the protocol during a possiblerevocation.

• The signer S, who will be signing p, PKp, thereby granting the user access. S can beone of the registrars or a different entity. S will need to be able to authenticate U.

2.5.2 Parameters

(N, e) and d The signers public key, and private key, respectively.

ER The registrars encrypting function. It can be decrypted by k out of n registrars. The

keys can be distributed without a trusted authority as was proposed in [39][23].

H a one-way secure hash function

p a security parameter. Increasing p will decrease the forging probability exponentially,

but will increase the overhead linearly.

2.5.3 The protocol

1. After authenticating herself, U chooses for i = 1, ..., 2p randomly r − I ∈ Zn, andstrings αi, βi. She then calculates ui = ER(m||αi) and vi = ER(ID||βi). She thensends mi = re

i H(ui||vi) (mod N) to the signer.

2. The signer then choses a subset S from 1..2k of size k, and send it as a challenge toU. This will ask U to demonstrate that mi’s are well-formed with high probability.

3. For every i, U sends ri, ui, βi as a challenge response.

4. For every i, the signer checks if mi is equal to rei H(ui||ER(ID||βi)) (mod N). If they

check, being convinced that all mi’s are well-formed, he sends back b = (∏

i/∈S mi)1/e

(mod N)

5. The signature can now be formed by s = bQ

i/∈S ri(mod N)

6. The signature can be verified by se =∏

(α,ν)∈T H(ER(m||α)||ν) (mod N)

12

7. Given the signature (s, T ), k out of n registrars can identify the user by calculatingID from the vis in T . Since the key for ER are shared between the registrars, itcannot be decrypted without at least k of them.

2.5.4 Security Analysis

Revoking Anonymity Without k Registrars The underlying secret sharing protocol

ensures that without k our of n registrars, they will not have sufficient information

to find the real id of a user.

Sending Messages Without Registering A valid message needs to have a valid

pseudonym/signature pair, so it is not possible to send a message without registering.

Note that the prevention of non-valid messages will be done on the implementation

level, where they will just be discarded rather than posted by the server.

Linking Messages to Users without Revokation Without k out of n registrars, they

will have the same information as the underlying fair blind signature protocol has, so

the safety of this protocol is satisfied if its safety is.

Sending Non-authentic Messages This requires the messages to be signed. Since a

malicious user would only have the public key, the security of the system is safe as

long as the underlying public key encryption system is safe.

Timing Attacks Like many cryptographic protocols, this protocol is susceptible to

timing attacks as well. The registrars can gather useful information on new users by

observing messages with new pseudonym. But solving this problem cannot be done

on the design level and needs to be taken into account at the implementation level.

2.5.5 Applications

Wikis Any collobration system where users might prefer to remain anonymous. Wiki’s

are a good example, as users might be interested in anonymity - especially for some

articles. Also having a single moderator that decides what is acceptable/right and

what is not is usually not desirable, especially since it is contrary to the democratic

spirit of wikis.

13

2.6 Future Work

1. Having a more thorough security analysis.

2. Having access control embedded into the system. One possible way of doing this isto use a master key generation algorithm [30] and encrypt the messages.

3. Possibly, design another protocol where no pseudonym is used and the user cansubmit messages, which can still be traced. Preferably any other messages can easilybe found after revocation. It is in fact relatively straightforward to do, if we dorequire a new registration for each message, or if we include the registrars to theregistration process, but both of these would reduce the practicality of the protocol.

14

CHAPTER 3ELECTRONIC VOTING

3.1 Introduction

Recently there have been many protocol proposals for electronic voting supporting

verifiable receipts. Although these protocols have strong theoretical foundations, most

current companies prefer to solve the verifiable receipt problem in a simplistic way by

having the voting machine print out an untraceble vote and deposit it to the voting box

after the voters examination. The electronic part is probably (details are usually lacking

and the systems are proprietary) still lacking strong cryptographic privacy and security.

Putting aside economical considerations, the main reason for this seems to be

the simplicity and ease of use of these systems. Ease of use is always an important

consideration in complicated software systems for obvious reasons, but simplicity in this

context has also an important additional advantage: it is easier to trust a system one can

understand.

In the light of these issues, improving the currently used systems rather than the

protocols that are theoretically sounder but are usually not employed might be more

productive. To this end, we try to use methods that are used in the literature that would

improve the existing systems, without reducing the stronger properties of said systems.

3.2 System Design Perspective

Rather than trying to improve on the work seen in the academia, the focus of our

research is to build a system as complete as possible that is both practical, readily

implementable by the industry and fits the related companies, government agencies and

especially voters needs and preferences, but also uses the cutting edge research done

by both academical researchers and companies and thereby has a strong theoretical

framework.

To accomplish this we first list the basic requirements and fundamental principles

along with preferable attributes. As much has been said about these issues both in

15

technical and non-technical papers, and in government and corporate white papers and in

the media, this part will include an organized compendium of existing ideas.

After that the preferences of all the involved parties (voters, government agencies

and companies) will be examined and in light of these preferences the currently marketed

systems as well as academic research will be evaluated. Using existing literature and

original research a new system (or possibly many) that fits all the players as much as

possible will be designed.

One important issue is the assumptions made by academic researchers (usually

without even knowing), and their practicality. As it is common in the security field, the

most important and easily circumvented problems are not addressed while the rather

inessential problems are examined to their deaths. (think of the weakest link of most

security systems: the user supplied password, rather than any cryptographic or design

part). Addressing these problems and analyzing them is of key importance.

3.3 Voting System Requirements

• The Privacy requirement ensures that each individual vote will be only known tothe voter. The voting machine is usually not included for obvious reasons, althoughsome system manage to even hide the vote from the voting machines.

• Individual Verifiability means that the voter can be convinced that his vote iscounted correctly, while universal verifiability means that any party can convinceitself that the election was fair.

• Receipt Freeness is required so as coercion and vote buying is prevented.Satisfying this propoert along with veriafiability is the usual challenge in designing avoting protocol.

• Robustness ensures that the voting protocol can recover from various errors andattacks.

• Convenience for the voters is often regarded as another requirement.

16

3.4 Building Blocks

3.4.1 Paillier Encryption

Paillier is a homomorphic encryption system, i.e. for messages a and b, and a key K,

it holds that EK(a) +EK(b) = EK(a + b), where EK(x) stands for encryption using the key

K.

Let n = pq, where p and q are prime, and let g be such that gcd(L(gλmodn2), n) = 1.

The public key then would be (n, g) and the private key λ = lcm((p − 1)(q − 1)). To

encrypt m < n, select a random r < n and compute c = gm · rnmodn2. To decrypt c < n2,

compute m =L(cλ mod n2)

L(gλ mod n2)mod n. For details see [33][5].

3.4.2 Proofs of Knowledge (Zero-Knowledge)

These are protocols where one player can prove knowledge of some fact to the other

player, without actually revealing the fact. Usually based on the challenge-response-verification

paradigm, in general they can be made non-interactive using the Fiat-Shamir protocol.[18][5]

3.4.3 Threshold [Homomorphic] Encryption Schemes

Threshold Encryption Schemes are protocols, where the private keys are shared, and

which can withold a certain number of malicious participants. See [5] for details on their

construction. Also check [21] and [16] to see for ways to make these trusted distributor

free.

3.5 Previous Work

E-voting protocols are one of the major subjects of cryptographic protocols. Earlier

protocols focused on privacy and voter verifiability.[25, 15] With the seminal paper of

Cramer et al. [13] receipt-freeness was introduced as an important requirement, and soon

after several solutions were published. [5, 22, 32, 7] Beginning with the use of DRMs, and

the publics scepticism of their correctness, paper receipts (or VVPR: voter verifiable paper

receipt) or individual or universal verifiability took the center stage as an important issue.

[29, 3, 9] Recently many technical and non-technical papers have discussed the security of

17

currently used voting devices, especially the use of paper-receipts[36, 14, 28, 4, 40, 20, 35,

31, 27]

3.5.1 Standard

What we call standard is basically generic protocol build on a simple but effective

idea, implemented in slightly different ways (possibly with various improvements/changes)

by some companies. What happens is that apart from the usual ’select your candidate

on the computer’ process followed by the results being sent to a central server (which

basically lacks many security properties that some proposed protocols satisfy), as

a paper-trail it also prints a paper-ballot of the said candidate and after the voters

inspection and confirmation, drops it to a box - to which the voter has no seperate

access. This paper ballot - which looks similar to a conventional paper ballot - is stored

for a possible recount. In a way the system tries to satisfy correctness by ensuring the

correctness of the backup vote only.

3.5.2 Major Issues with the Standard System

Consistency In the standard voting protocol, there are actually two seperate votes cast.

Of course the system descriptions will necessarily indicate that those two votes will

always be the same, however both designing and implementing this requirement

and convincing the public that this will always be the case is a problem that needs

to be addressed. The reason this problem might manifest itself is closely related

to the laws and rules of the election. Since voters will have visually reviewed the

paper ballots, those will be the trustworhy ones. But if these are only to be used

on possible recounts, in districts where getting a rulling for a recount is relatively

difficult their positive effect to the reliability of the election will be dimnished. This

problem can trivially be solved by having the paper ballots be assigned the role of

the real votes - rather than just a backup. In that case the electronic counts will acts

merely as an unofficial exit poll. This however reduces the usefulness of an electronic

voting scheme, so looking for a better alternative makes sense. One alternative is

18

to ensure correctness seperately, for example by using cryptographic techniques

similar to ones without paper ballots. Another direction is to reduce the potential

inconsistency between the electronic and the paper ballot, for instance by having a

table of all the paper ballot votes indexed by their id’s, and then randomly check a

predetermined amount of the ballots thereby testing if an inconsistency has occured

with a calculatable probability. This of course will need to be designed carefully, as

the id’s might be used for coercion. It is in fact hard to see how the problems caused

by this indexing will be easier to solve than the problem it is solving. Hence, we will

go in the other direction.

Coercian Resistancy This problem might represent itself if it is possible to use a

picture of the paper ballot as a proof. It all depends on what the system does if

at the confirmation (of the paper ballot) phase the voter wants to change his vote

(either because there was an error, or because of the voter changing his mind). If

this process is easily recognizable by an outsider, the picture of the ballot at the final

confirmation phase can be used for vote buying. As this problem can be solved at

the implementation phase, we will not go into any details.

Privacy Unlike traditional voting, any electronic system which relies on the DRM

to record/submit the vote has to consider the privacy issues carefully. Chaum’s

protocol [11] circumvents this problem by not disclosing the vote to the DRM,

but allmost all other systems are at least somewhat suspect to vote recording and

matching them to voters. There are a few ways to reduce the possibility of this

by designing the voting procedures carefully. In case there are multiple booths

(which is the case in most districts), if the public cannot see which voter goes into

which booth, the probability of a successfull matching of votes and voters dimnishes

radically. Even if all DRM’s are malicious, a confident match might be too hard. Of

course this also depends on how the voter actually presents itself as a qualified voter

to the DRM. Some ways that the information can be saved and later on retrieved

19

are: by using the available storage and then make network connections, by using

backdoors, subliminal channels, or similar techniques.

3.5.3 Pret-a-Voter

3.5.3.1 Introduction

This is a practical improvement on Chaum’s image based protocol[10]. It is based on

an idea from [34]. One of the key points of this protocol is that the voting device never

learns the intended vote, thereby eliminating several security risks directly. Basically the

pre-prepared ballots have what is called an onion, which is an encrypted form of the order

the candidates are listed. The user selects his candidate from a shuffled list, marks it in

the voting booth, and on his way out drops part of the ballot to the voting box. This

part does not have the candidate list, so using only this part and without decrypting the

onion it is impossible to know for which candidate the vote is for. The selected candidate

can only be seen after the encryption is opened - which happens after an anonymizing

step. The part that the voter keeps is used as a receipt - it cannot be used to prove which

candidate was selected, but it can be used to verify that the correct encrypted vote was

submitted to the server. The main issue with this approach is the extensive need for

setting up the ballots and the implied complexity, which causes an increases of potential

pitfalls and a decrease in perceived security of the system.

3.5.3.2 Details

The ballots in this protocol consists of two seperable parts. One part will have a

randomly ordered list of the candidates. The other part will have the so called onion,

which can be used to reconstruct the ordering. This second part is also where the voter

mark his choice. These ballots will be distributed before the election starts, and they will

be randomly audited for correctness. In the voting booth, the voter will seperate the two

parts of the ballot, and feed the part which has the onion into the voting machine. Since

the voting machine will not see the ordering, it will not know which candidate the voter is

voting for.

20

As the security of the election would depend on the correctness of the ballots,

auditing the ballots before the election is an integral part of this protocol. There are

several different checks for correct ballot construction, each with a different level of

thouroughness. Here is a list and brief descriptions:

1. Single Dummy Vote: Here Anne just casts a dummy vote, and sends the receipt tothe tellers. The tellers open the vote and inform Anne of the apparent vote.

2. Multiple or Ranked Dummy Vote: This is very similiar to the previous one repeatedseveral times in succession.

3. Given the Onion Value the Tellers Return the Candidate Ordering

4. Return the Seed, and run the checking algorithm for well-formedness: Unlike thefirst three checks, this one is not readily vulnerable to collision attacks. This mode4 check is described in detail in the paper, but one assumption that is made thatstrengthens this audit is that the onion function is bijective.

Once the ballot is cast, the voting device submits the vote (same as the receipt) to the

bullettin board. The tellers then start to process the votes, by decrypting their part. At

the end the plain votes will be published, but the links to the initial receipts will be lost.

Checking that the vote recording devices work correctly is done mostly by the voters, who

can verify if their receipt is posted on the bullettin board. It should also be checked that

no extra vote is cast, which can be done by comparing the counts and/or by use of digital

signatures. Checking on the tellers if they performed the mix correctly is by randomly

picking either the incoming or outgoing edge for each vote and asking the teller to verify

correctness. Since each teller performs two mixes, this does not contradict privacy.

3.5.4 Homomorphic Encryption Based Protocols

The main idea with these protocols is that votes are sent to a central server encrypted

with a shared key (after a mixnet phase), and they are first combined and then decrypted.

So no ballot is actually decrypted seperately, which helps prevent linking of encrypted and

opened ballots. These protocols were more popular before the need for verifiable receipts

were generally agreed as a requirement.

21

Forsythe proposed[19] a generic method for adding voter verification to homomorphic

encryption based election systems, using a cut-and-choose[6] approach – an idea which

was used before in different settings[22]. We use this procedure in our homomorphic

encryption based system, albeit after some corrections /modification and completing of

several missing details.

3.5.5 Possible Reasons for not adobting advanced cryptographic schemes

1. Practicality

(a) Need for setting up a complicated and distributed mix-net. (most moderncryptographic voting protocols use mixnet for some reason or other). Theseare generally used to shuffle the ballots so that any links between the resultingvotes and the voters are lost. The questionable part of this method is that(unless the DRM does not now the vote itself - like in Chaum’s protocol), it isvery difficult to protect the privacy if the DRM itself is compromised. In a way,these methods are not strengtening the weakest link, nor are they protectingthe most important property of a successful election: it’s correctness.

(b) The usual cut-and paste schemes or Chaum’s use of encrypted ballots result inrather complicated interfaces. This is contrary to one of the main ideas of usingelectronic systems, which was to simplify the process for the voters.

2. Trust The belief that paper ballots are sufficient as verification. People trust aballot they can understand more than a technically sound cryptographic receiptwhich has confusing numbers/letters on it. It is important not only to have a secureelection, but also to have an election which people believe to be secure.

3.6 Protocol 1

The voting protocol is in a way a combination of Pret-a-Voter (which has the

desirable property of the DRM not learning the selected candidate) and the current

standard idea in the industry of having the DRM generate the human-readable ballot

(for auditing purposes; these ballots are very similar to the usual paper ballots) as the

only audit trail. The strength of that method is its simplicity (especially because it makes

the setup reliable in the eye of the voter), but it does not use cryptography to its full

strength so that the electronic votes will not be as trusted as other systems and extensive

use of audit-trails will mostly defeat the purpose of electronic voting machines. Our

22

protocol will try to combine these two systems by taking the security of the first system

(thereby reducing the need for full recounts by reducing the threat levels) and the paper

trail making a full recount possible and increasing the trust of the voters. Improvements

include:

• Ability to have real receipt making a recount possible

• No use of ink/stamp. All done electronically (or rather by the DRM), except forpossible recounts.

• Arguably easier to use.

Advantages compared to similiar proposed protocols:

• Support both full recounts and full privacy.

• Relatively simple. No need to select a candidate from a big grid.

• Reduced possibility of false (or possibly false) accusations of malfunctioning. Printschoice, then asks if sure, then prints ballot and asks for confirmation.

3.6.1 Scenario

Voters feed a prepared ballot to the DRM. The ballot has 3 parts. The first part has

(along with the onion as a barcode) the empty spots (aligned with the candidates), which

the DRM will mark as the vote. The second part has the candidates listed in a random

order. The last part has the human readable onion - which works as the ID of the ballot.

It will be used to map the marks to the candidates. The user feeds the ballot to the DRM.

At this stage only the first part will be inside the DRM, until to voter selects the spot he

wants to be marked (not directly the candidate - so the DRM won’t know which candidate

is selected). After he confirms his choice, the printer will print the receipt and submit

the vote to the server. This part will be very similar to Pret-a-Voter. It will then take

the second (un-seperated) part and leave the third part for the user. The first and second

parts together will be the paper-trail - making it possible to have a recount.

23

3.6.2 Details

The math behind the onion is very similar to Pret-a-voter. But there are some

differences. Firstly, since there will be paper ballots for possible recounts, some requirements

might be relaxed. Secondly (and more importantly), one needs to make sure that the

DRM actually marks and submits the correct number as the selected candidate. (As there

will be one electronic and one paper vote, both of these should be verifiably correct) This

will mostly be easily checked by the voter, but care must be taken to prevent the DRM

from possible cheatings. The key part is to make sure that the selected number will be the

same as the actual choice - which will mostly be the voters responsibility. After the voter

selects his choice, and the DRM marks the spot, it also prints the first part of the receipt.

This receipt will also include the selected order, and so in a way this receipt will include

all the information of the printed receipt and ballot leftover part from Pret-a-Voter.

3.6.3 Security

Some possible issues that need to be analyzed in detail:

• Making sure that the submitted electronic vote is correct and private - particularlythere should be no way the DRM can construct a correct vote on his own. This ismostly taken care of by the Pret-a-Voter part.

• The paper ballot should be correct and the same as the electronic vote. This ischecked by the user, who can alert authorities if a mismatch occurs.

• Matching the receipts with the paper-ballots should be impossible (or at leastdifficult). This property is currently not satisfied - but it should be possible to do so.

• To prevent the V D from reading the candidate order, fonts that are difficult to readby scanners can be employed.

• Write-ins might be added, but they will be non-trivial to use.

• Specially marked ballots might be used for coercion. To prevent this one might letthe V D print a copy of the receipt part of the ballot and keep the original.

3.7 Protocol 2

This protocol is a combination of classic homomorphic encryption schemes, and the

standard method. Unlike the previous protocol, the V D will have the voting information,

24

but to prevent cheating the cut-and-paste method will be used. As an advantage to the

previous method, no paper ballots will be necessary to vote, the final paper ballot and the

receipt will be printed by the V D. The only additional burden (for to the voter) would be

the need to select the preferred candidate from a grid. This might be confusing for some

users, but even very simple initial instructions would make it easy to use for the average

voter. The advantage would be the extra certainty that the electronic vote counted as

intended.

Apart from combining the standard protocol with a homomorphic encryption based

protocol, we also demonstrate a possible method for supporting write-in ballots, although

the method would probably not be practical in real elections. The details regarding these

ballots are given in a subsequent section.

3.7.1 Protocol Specification

3.7.1.1 Participants

Authority The authority A will be responsible for the calculating and announcing the

final tally.

Voting Device The Voting Device VD gets the votes from the voters and submits them

to the BB. VD uses a computer screen S to display information to the voter. It also

uses a printer to print a receipt R for that purpose. The difference of these is the fact

that D will remain secret between the voter and the voting device, whereby R will be

taken outside the booth by the voter. Finally it will also print the paper ballot and

deposit it into th eballot box.

Voter The Voter V uses VD to submit a vote for his selected canidate.

Bulletin Board The Bulletin Board BB is where the VD submits the votes. It is publicly

readable, and write-only for the VD. A will read the votes from here.

Coercer The Coercer C is a hypothetical participant.

25

3.7.1.2 Voting

This phase occurs inside the voting booth, so it is assumed that there is a private and

secure channel between V and VD. The only information that will be revealed to an outside

party is the vote submitted to the BB by VD, and the receipt R printed by VD.

1. VD displays a d × n matrix, where d is a security parameter, and n is the numberof candidates (including a generic ’write-in’, and a possible abstain). Each row inthis matrix consist of these candidates in a random order. If the voter requests, VDgenerates another grid with the same properties. This prevents a forced-abstentionattack[26] – i.e. prevents the Coercer to ask the voter to vote for a specific row andcolumn thereby effectively randomizing his vote. (This attack was not mentioned in[19] and the possible repetition is the only difference from her procedure we adopt)

2. VD also prints a commitment for this matrix, using a one-way hash with randomsalt. This salt will be revealed when the commitment needs to be opened. (Thecommitments can be based on each entry or on each row) hese commitmentsessentially follow the same lines as [19], and insures with d−1

dprobability that the

vote will be cast as intended.

3. V first randomly choses a row, and then submits his chosen row and column (andthereby candidate). If the voter decided to vote for a write-in candidate, he fills outa write-in ballot, removes the top part and discards it, then submits the lower partwith the encrypted name and onion to the VD. In that case the encrypted name willbe submitted to the BB as given, otherwise it will be an encryption (with the publickey of the Authorities) of 0.

4. After the candidate selection, VD prints the paper ballot and waits for a confirmation.After the confirmation it deposits the paper ballot and opens the commitments forunchosen rows by printing the random numbers used for the commitment. It alsoprints the selected row and column, but not the name of the candidate.

5. Once the VD has the voter’s choice, he forms the vector ballots as described in [29],and publishes them to the BB along with the zero-knowledge proofs.

6. If the candidate was ’write-in’, V uses the write-in ballot to print the encrypted nameand the onion.

3.7.1.3 Tallying

Once all the ballots are cast and submitted to the BB, A will take the pre-listed

candidate part and add all the encrypted ballots and decrypt the result - adding proofs of

correctness of the decryptions, thereby getting the final count. Note that this is different

26

than the usual homomorphic encryption based voting scheme, where usually there is

mixing phase. The reason for the mixing phase is that no single authority can reconstruct

the link between the encrypted and decrypted ballots. But in our case that would not

accomplish anything, as the VD already knows the ballots. Also the paper ballots will also

have all the votes, and can be used for a possible recount.

When it comes to tallying the write-in parts, there are two options. The first one is

to use a mix-net. This will hide any links between the final votes and encrypted ballots,

and the write-in voters will have full privacy. However, as the regular parts didn’t use a

mix-net, one can also just let A decrypt the votes. Here privacy will not be as strong, but

it will still be similar to the regular votes, and correctness will still be satisfied.

3.7.2 Write-In Ballot Overview

3.7.2.1 Vector Ballots

The initial ballots will contain both the pre-listed candidate portion and write-in

portion. They will consist of 3 seperate parts:

Pre-Listed Candidate portion This part will consist of an encryption of either 0, or of

one of the choices {1, M, M2, . . . , Mn}. (See [29] for a more efficient method)

Flag This will be an encryption of 0 if a pre-determined candidate is chosen, 1 if a

write-in candidate is chosen.

Write-In portion This will be a secret permutation of the chosen write-in candidate, or

an encryption of 0 if a pre-listed candidate is chosen. Rather than 0, a longer string

in the form of 0n might need to be used to have the two type of encryptions have the

same length and be indistinguishable.

Apart from the write-in candidate’s name (if any), all encryptions will be done using

the Authorities public key. For each posted ballot, the VD will publish a zero-knowledge

proof, showing that at least one of the following is true:

• The first part is an encryption of 0 and the second part is an encryption of 1

27

• The first part is an encryption of an element from the given set of choices, the othertwo parts is an encryption of 0

One point that needs to be emphasized is the fact that the write-in candidate (if chosen)

is not really encrypted with the public key of the Authorities. But as one can see from

the above list, the only case where that part is relevant is when it is supposed to be an

encryption of 0, so this does not present itself as a problem. So the zero-knowledge proof

is exactly the same as proposed by Kiayias and Yung, hence details can be found in [29].

3.7.2.2 Pre-Listed Candidates

Once the election is finished and the zero-knowledge proofs are verified the tallying

phase starts. Since at this point it has been verified that at most one part of the ballot is

used, one can safely seperate the ballots into two parts:

• The pre-listed candidates, as represented by the set of choices

• The flag and the write-in part portion. The flag may be necessary for the shrinkphase that will get rid of some empty write-in votes (those will have been votedfor a pre-determined candidate and their vote will be counted using homomorphicencryption).

Counting the first part will be straightforward, thanks to the homomorphism property.

Each vote will be added, and the resulting ciphertext will be decrypted by the Authorities,

using their secret shares. Note that for ballots for which write-in candidates were chosen,

the counts will not be affected. When this step is finished, depending on the election

procedure, the results can be announced unofficially (if it can be deduced that the

remaining write-in votes will not affect the result), or the results from the write-in parts

will be waited for.

3.7.3 Write-in Ballot Details

The write-in ballot forms will be prepared and printed before the election. They

will be distributed to the voting booths, but care must be taken that only official

ones are actually in the booth. Randomly sampling these ballots and checking their

construction should be part of the security measures taken[11]. The ballots themselves will

28

be consisting of 4 parts. The main part will be a grid of k × l, where k is the size of the

required alphabet (probably the English alphabet along with special characters like space

and punctuation marks), and l is the maximum number of characters a write-in name can

contain. The grid will be filled with symbols from the alphabet, such that each column

will have each symbol exactly once, in a random order. The top of the grid will have l

boxes, aligned with the columns, for the name of the chosen candidate, and will be mainly

used to facilitate constructing the ciphertext. The left part will consist of the alphabet,

in order, and aligned with the rows. This also is for aiding the voter in constructing the

ciphertext. At the bottom will be a detachable part, consisting of l aligned boxes for the

ciphertext, along with the onion, which will be explained in detail later. In effect the

form will be a one-time pad, and the voter will need to make the encryption. This will

arguably be too complicated for many voters, but with a clear design and easy to follow

instructions, the majority of voters should be able to do it within a minute. Considering

the fact that most voters do not use the write-in part, this should not be too serious a

concern.

In Figure 3-1 the sample ballot shows how a voter wishing to vote for candidate

“Bob” would work out the ciphertext. The lower part that will be fed to the device is

where the string (ciphertext) “DLK” and the onion appears.

The write-in ballots will be formed using a modified version of Chaum’s use of onions,

which was used for pre-listed candidates only.

To understand the underlying idea of the following construction, consider Chaum’s

construction of the onions. The use of germs worked as a simple permutation (actually

just an offset, but in principle can be considered a permutation, and in our case the

analagous construction will be a permutation), and as the ballot is transfered from teller

to teller, this permutation was combined with other permutations, at the end getting

the final permutation, which is used to construct the actual vote using the index. Note

that technically, each teller could have shifted the index, rather than transforming the

29

Figure 3-1. sample write-in ballot

permutation (Obviously the shift would have been the inverse of the permutation). This

observation will be the key idea in our construction.

3.7.3.1 Construction

Each teller T| generates 2l random numbers ri from a field of size 2h, for which

2h > s! holds, where s is the alphabet size. So for an alphabet of size 30, h = 72 should

be sufficient. Each of these numbers will map to a specific permutation of letters be a

pre-determiend algorithm. Note that this size can be reduced by having a partial set of

permutations to chose from. The composition of these permutations will form the actual

permutation used in the ballot. (Unlike in Chaum’s protocol, the use of hash values rather

than ri is not really necessary, as the guessing attacks would not be feasible here.) The

way the onion and the final permutation will be constructed by the same formula given by

Chaum:

Di+1 := {ri, Di}PKTi

Onion := D2k

30

In effect this will be done for each of the l letter, and each D0 will be a random number.

To make this idea work in our scheme, we also need to add a control string (either a

specific predetermined string or a checksum would work) of some pre-determined length

c. The reason for this is the fact that the mix will start not only with the actual write-in

votes, but also with the 0 encryptions from voters who voted for a pre-determined

candidate. As each germ is opened by the tellers, if this control string does not match,

the pair (i.e onion and ciphertext, which are actually in one string) is discarded. If there

are k tellers each performing 2 mixes, the probability that an encryption of 0 will not be

discarded is 2−dk. So increasing d sufficiently will reduce this to almost zero. Note that

even if such a string is not discarded, it will just be a random string after decryption, not

interfering with the election results. Note also that the last teller (or the first one when

decrypting) should not have this check, as that will make the teller able to conclude that a

vote was not for a write-in with 1 − 2−d probability.

3.7.3.2 Opening Ballots

To extract the write-in vote, for each ballot, each Teller will perform the following

actions for each letter:

• Open D2i+2, to get r2i+1. If the redundant string does not check, discard the pair,otherwise apply the inverse transformation specified r2i+1 to C2i+2, which is theciphertext, C2k being the text entered by the voter. Mix the ballots. Submit theresulting ballots to the BB.

• Repeat the same process once more. The resulting ballots will be the starting pointof the next Teller.

3.7.3.3 Auditing

Since each Teller performed two mixes, for each ballot in the middle column,

either the incoming or the outgoing link will be chosen, which the Teller will verify by

revealing the link and the relevant random number. As in [? ], the use of two mixes

insures anonymity.

31

3.7.3.4 Proofs of Knowledge

Several types of zero-knowledge proofs are provided in [5]. How to get a zero-knowledge

proof for the vector-ballot is explained in [29]. The auditing phase requires the tellers to

prove correct shuffling and decryption, which was demonstrated in [? ]. The idea is for

the teller to reveal the germ value and show that it satisfies the necessary constrains. The

same method will be used in our protocol. For all dropped pairs, germs which do not

satisy the redundant string checks are revealed and demonstrated.

3.7.4 Analysis

3.7.4.1 Receipt-Freeness

The pre-listed candidates will be listed in a random order, and the selected row will

not be opened at all, so there will be no way for the Voter to prove his vote. For the

write-in part, if a Coercer can get a valid and authentic ballot before the election, then

he can force the voter to use it and ensure that the write-in selection will be his choice

(the same vulnerability also seems to exist in Pret-a-Voter). The prevention lies in not

making the ballot forms available before the voting-booth, except for auditors. Another

potential insecurity is the destruction of the upper part of the ballot, as this in addition to

the receipt can be used as a proof for the name of the write-in selection.

3.7.4.2 Vote cast as intended

For the pre-determined list of canidates, the voter is convinced with d−1d

probability

that the vote is cast as intended. But with 1d

probability the voting device can change the

vote to another canidate. Still with a sufficiently large d, cheating several times without

getting caught is highly unlikely. Of course having a fair recovery strategy is still of great

importance. Since the encryption for the write-in part is verified, the only possibility for

changing the vote remains in tricking the voter to use non-authentic ballots. Chaum has

some defenses listed against this attack in [? ].

The paper ballots on the other hand will have been reviewed by the voter, so he will

be convinced it is correct. Satisfying correctness this way in turn will imply consistency.

32

3.7.4.3 Authority-Voting Device Collision

This is the most serious problem with our protocol, as usually the systems representing

the authority and the voting device will be designed by the same entity. However the same

applies for almost all e-voting systems in use today, and our proposal has at least some

counters against it.

3.7.4.4 Coercer-Voting Device Collision

On of the weaknesses of electronic voting protocols is the difficulty of defending

against the collision of a Coercer and the Voting Device. Although the protocols we

mentioned prevent the changing of votes, most of them have only limited defenses to

protect voter anonymity. Since Pret-a-Voter does not let the voting device know the

selected candidate, this is not a problem, but the other schemes do not have sufficient

protection. If the Voting Device can either during the election or afterwards submit the

records to the Coercer, privacy can easily be invaded. Even physical security against

this might not be sufficient, as subliminal random channels might convey the necessary

information rather easily[27]. Unfortunately our protocol does not have any additional

defense to this attack either.

3.7.4.5 Denial of Service Attacks

Denial of Service attacks are also a possibility in most electronic voting systems.

Preventing these seems to be solved by early detection and recovery, which makes it fragile

and necessary for very thourough recovery procedure planning. Again, our system does

not have any additional defenses against these types of attacks.

3.7.4.6 Election procedures to improve security

One problem that needs to be addressed in our protocol is the issue of write-in

ballot distribution. If these are distributed freely and early so that various audits and

checks can be made, it will increase the possibility of coercion. But without any audits

the correctness of these will be an even more pressing problem. So the procedures to be

33

followed for this purpose must be carefully examined and weighted against these potential

problems.

3.7.5 Comparison

3.7.5.1 Comparison with Pret-a-Voter

• A paper audit-trail. Votes can be recounted.

• The candidate list is needed, so it cannot be kept (and potentially used for votebuying etc). The design is such that even if the DRM reads the list (since it willhave the hardware necessary for it - to be used for reading the barcode), the desinginsures that the commitments (pretty much everything that will be submitted to theserver) are already printed, as is the paper vote itself.

3.7.5.2 Comparison with Standard

Almost everything that Pret-a-Voter can do compared to Standard, this protocol can

do. This mostly includes greatly improved privacy, voter verification of the electronic vote,

and again greatly increased correctness. The only major drawback of this protocol is the

additional overhead - especially when it comes to the write-in ballots.

3.8 Future Work

1. Give a more detailed overview of previous work, especially Pret-a-Voter and ahomomorphic encryption scheme.

2. Complete the listing, description and evaluation of potential security and otherproblems with the standard system and propose potential solutions for these issues.

3. Possibly simplify the homomorphic encryption based system (with voter-verificationsupport). and/or improve the consistency of the electronic and paper ballots in thestandard system.

34

CHAPTER 4SCHEDULE

1. February: Start implementing access control into the anonymity protocol. Completethe description of previous work and details of existing voting protocols andanonymity protocols.

2. March: Finish access control. Improve the security analysis of the anonymityprotocol.

3. April: Improve security analysis of the voting protocol.

4. May: If possible (and there is sufficient time) consider the problem of removingpseudonyms from the anonymity protocol, or try to simplify/improve voting protocol

5. June: Complete any remaining work.

6. July: (or early August) Defense.

35

REFERENCES

[1] Anonymizer. http://www.anonymizer.com/ .

[2] Tor project. http://www.torproject.org/ .

[3] Acquisti, A. Receipt-free homomorphic elections and write-in ballots.

[4] Bannet, J., Price, D. W., Rudys, A., Singer, J., and Wallach, D. S.

Hack-a-vote: Security issues with electronic voting systems. IEEE Security and

Privacy 2, 1 (2004), 32–37.

[5] Baudron, O., Fouque, P., Pointcheval, D., Poupard, G., and Stern, J.

Practical multi-candidate election system, 2001.

[6] Brassard, G., Chaum, D., and Crepeau, C. Minimum disclosure proofs of

knowledge. J. Comput. Syst. Sci. 37, 2 (1988), 156–189.

[7] Byoungcheon, V. P. Providing receipt-freeness in mixnet-based.

[8] Camenisch, J., Maurer, U. M., and Stadler, M. Digital payment systems

with passive anonymity-revoking trustees. In ESORICS (1996), pp. 33–43.

[9] Chaum, D. Secret-ballot receipts: True voter-verifiable elections. IEEE Security and

Privacy 2, 1 (2004), 38–47.

[10] Chaum, D. Secret ballot receipts: True voter-verifiable elections. IEEE Security and

Privacy, 2(1):38-47. Jan/Feb 2004 (2004).

[11] Chaum, D., Ryan, P. Y. A., and Schneider, S. A. A practical, voter-verifiable

election scheme. Tech. rep., University of Newcastle upon Tyne, 2004.

[12] Claessens, Joris; Diaz, C. G. C. P. B. V. J. D. J. Revocable anonymous

access to the internet? Internet Research (2003), 242–58.

[13] Cramer, R., Franklin, M., Schoenmakers, B., and Yung, M.

Multi-authority secret-ballot elections with linear work. Lecture Notes in Com-

puter Science 1070 (1996), 72–??

[14] Crane, R., A. K. A. D. E. C., and D.Mertz. A deeper look: Rebutting shamos

on e-voting, 2005.

36

[15] Cranor, L., and Cytron, R. Sensus: A security-conscious electronic polling

system for the internet, 1997.

[16] Damgard, I., and Koprowski, M. Practical threshold rsa signatures without a

trusted dealer, 2000.

[17] Davida, G., Frankel, Y., Tsiounis, Y., and Yung, M. Anonymity control in

E-cash systems. In Financial Cryptography: First International Conference (Anguilla,

British West Indies, 24–28 1997), vol. 1318, Springer-Verlag, pp. 1–16.

[18] Fiat, A., and Shamir, A. How to prove yourself: Practical solutions to

identification and signature problems. In Advances in Cryptology — Crypto ’86

(New York, 1987), Springer-Verlag, pp. 186–194.

[19] Forsythe, J. M. Encrypted receipts for voter-verified elections using homomorphic

encryption. Master’s thesis, M.I.T., 2005.

[20] Foundation, E. F. Accessibility and auditability in electronic voting. White Paper.

[21] Fouque, P.-A., and Stern, J. Fully distributed threshold RSA under standard

assumptions. Lecture Notes in Computer Science 2248 (2001), 310–??

[22] Hirt, M., and Sako, K. Efficient receipt-free voting based on homomorphic

encryption. Lecture Notes in Computer Science 1807 (2000), 539+.

[23] Ingemarsson, I., and Simmons, G. J. A protocol to set up shared secret

schemes without the assistance of mutually trusted party. In EUROCRYPT ’90:

Proceedings of the workshop on the theory and application of cryptographic techniques

on Advances in cryptology (New York, NY, USA, 1991), Springer-Verlag New York,

Inc., pp. 266–282.

[24] Jakobsson, M., and Yung, M. Revocable and versatile electronic money. 3rd

ACM Conference on Comp. and Comm. Security (1996), 76–87.

[25] Juang, and Lei. A secure and practical electronic voting scheme for

real world environments. TIEICE: IEICE Transactions on Communica-

tions/Electronics/Information and Systems (1997).

37

[26] Juels, A., and Jakobsson, M. Coercion-resistant electronic elections, 2002.

[27] Karlof, C., Sastry, N., and Wagner, D. Cryptographic voting protocols: A

systems perspective, 2005.

[28] Keller, A. M., and Mertz, D. Privacy issues in an electronic voting machine.

In In Proceedings of the ACM Workshop on Privacy in the Electronic Society (WPES

(2004), ACM Press, pp. 33–34.

[29] Kiayias, A., and Yung, M. The vector-ballot e-voting approach, 2004.

[30] Kiesler, T., and Harn, L. Cryptographic master-key-generation scheme and

its application to public key distribution. Computers and Digital Techniques, IEE

Proceedings - 139, 3 (May 1992), 203–206.

[31] Neff, C. A. Election confidence. Tech. rep., VoteHere, Inc, 2003.

[32] Okamoto, T. Receipt-free electronic voting schemes for large scale elections. In

Security Protocols Workshop (1997), pp. 25–35.

[33] Paillier, P. Public-key cryptosystems based on composite degree residuosity classes.

Lecture Notes in Computer Science 1592 (1999), 223–??

[34] Ryan, P. Y. A. A variant of the chaum voter-verifiable scheme. In WITS ’05:

Proceedings of the 2005 workshop on Issues in the theory of security (New York, NY,

USA, 2005), ACM Press, pp. 81–88.

[35] Sastry, N., Kohno, T., and Wagner, D. Designing voting machines for

verification. In USENIX-SS’06: Proceedings of the 15th conference on USENIX

Security Symposium (Berkeley, CA, USA, 2006), USENIX Association, pp. 22–22.

[36] Shamos, M. I. Paper v. electronic voting records an assessment, April 2004.

[37] Stadler, M. A., Piveteau, J.-M., and Camenisch, J. L. Fair blind signatures.

Lecture Notes in Computer Science 921 (1995), 209+.

[38] Stefan Kpsell1, R. W., and Federrath, H. Revocable anonymity. In Emerging

Trends in Information and Communication Security, vol. Volume 3995/2006 of

Lecture Notes in Computer Science. Springer Berlin / Heidelberg.

38

[39] W.-A. Jackson, K. M. M., and O’Keefe, C. M. Efficient secret sharing without

a mutually trusted authority. In Advances in Cryptology – EUROCRYPT ’95 Lecture

Notes in Computer Science 921 L. C. Guillou and J.-J. Quisquater, eds. (New York,

NY, USA, 1995), Springer-Verlag New York, Inc., pp. 183–193.

[40] Walter R. Mebane, J. Who won? statistical election fraud detection. 2006

USENIX/ACCURATE Electronic Voting Technology Workshop, Keynote Address,

2006.

39