Re: open-audit elections

From: Ben Adida <ben_at_eecs_dot_harvard_dot_edu>
Date: Wed Dec 13 2006 - 10:08:14 CST


The VoteHere documentation can be found at:

though some of it is a bit out of date and also a bit too detailed as a
first read. A simpler description is given in a paper Andy and I
co-wrote to describe the general concept of "ballot casting assurance:"

(I take no credit for Andy's proposal, this paper only summarizes it to
make a larger point.)

> 1) How do we solve the key control issue? If the key leaks, or is
> broken, anytime between now and infinity all the ballots can be
> identified with individual voters. What's the design principle that
> fixes this?

This is a great question, and the only reason I put it off is because I
wanted to address some higher-level issues first.

The design principle that applies here is threshold decryption. There is
no single key. There are a dozen keys, each held by different parties:
one by Democrats, one by Republicans, one by the Election Officials, and
so on... You need *all* of them to be compromised before privacy is

Note that this does not involve generating a single key and then
splitting it into pieces. Each party actually generates a key on its
own, independently, so there is never, in a single physical location, a
single key that, if compromised, could destroy the privacy of the election.

Note that, after the election, it is expected that the secret portion of
the keys would be destroyed, leaving only the public portions for
verifiability. You only need *one* of the keys to be appropriately
destroyed to ensure that votes can no longer be decrypted.

> 2) How does the voter verify at the poll that his receipt is an
> encoding of his chocies and not something else?
> i) example 1:
> Let's suppose that the vote here system used a paper ballot opscan
> input. What happens when there's a misscan? does the votehere
> receipt in anyway tell the voter that his ballot was misread?
> ii) example 2: Same question if it's a touchscreen that is
> malfunctioning.

The description from the "Ballot Casting Assurance" paper above explains
this, I think, but let me know if it's still confusing.

The key idea is that there is a short interaction between the machine
and the user that yields a confirmation code next to the chosen
candidate's name on the receipt. There's some math in there that means
the machine can't cheat, or it will get caught by just running a simple
verification program on the receipt (that anyone can write.)

> 3) when the voter calls City hall and deterimes he receipt was
> present, what exactly is that telling him? How does this prove his
> ballot was counted or counted as cast?

There's a long'ish unique code on your receipt, you ask if that code is
present on the voting list. (Alternatively you can just give your name
and have City Hall read off the number to you and you just check that it
corresponds.) When City Hall certifies the election, they have to
produce these codes, including something like a hash of all of the codes
that can easily be published in newspapers for public verification of
the whole list.

Thus, you can ask any other organization you trust, like the LOWV, the
ACLU, etc... to check the list for you.

I'm glad you're asking these questions, because I think the key
idea---that verification can be done using data published by machines
and election officials---is coming across as a result.

OVC-discuss mailing list
= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
Received on Sun Dec 31 23:17:12 2006

This archive was generated by hypermail 2.1.8 : Sun Dec 31 2006 - 23:17:16 CST