Re: open-audit elections

From: Ben Adida <ben_at_eecs_dot_harvard_dot_edu>
Date: Tue Dec 12 2006 - 23:11:53 CST

Hi Kathy,

I'll start with a high-level description of what an open-audit system
does, as I've been a bit vague on this so far. This isn't a complete
description, but it's a start.

I want to mention that this stuff is *not obvious*. There are some
really powerful techniques at work here (that I take no credit for), and
it's worth looking into because there's a lot of FUD.

So, the process:

1) Alice prepares her ballot (using paper or a computer, there are
protocols for either), and obtains, in the isolation booth, a "secret
receipt" (effectively the encryption of her vote).

2) Alice casts her encrypted ballot. This does *not* need to be
anonymous, since the ballot is encrypted.

3) A list of voter names and their respective, encrypted ballots is
published for all to see.

4) Alice checks that her receipt matches the published ballot under her

5) Election officials tally the encrypted ballots, providing
mathematical proofs that the tally was done correctly.

Anyone can write a program to verify this proof (it's fairly simple
code, likely doable in an Excel spreadsheet.)

The main idea is that, if enough voters check their ballots (1% or so),
then, with overwhelming probability, the vote casting was done
correctly. Also, *anyone* can verify the tally, including the LOWV, the
ACLU, etc...

The main idea that makes this different from non-open-audit systems is
that the vote remains tied to the voter, so auditing can be performed
all the way to the tally. With the encryption layer, the votes remain
anonymous (I know Charlie has an objection to this, which I'll address
in a followup email.)

Kathy Dopp wrote:
> I see some logic errors in your statements... which I shall address
> one at a time below.

I started responding to each one, but this started to yield an endless
email that would put most people to sleep. Instead, let me address what
I think are the biggest misconceptions.

I hope you won't find this unfair to the points you made: I'm willing to
argue all of them, but I want to focus on the important ones first. My
email is long enough as it is :)


> To the average voter "complexity = lack of transparency".

Except that's incorrect. The average voter can be wrong (the average
voter thinks DREs are great, so clearly there's a problem). It's
important to use words that are precise.

I can see why people would think that "complex systems can't be used for
elections," and we can discuss that statement. But to say that
complexity implies lack of transparency is not a matter of opinion, it's
factually wrong.


> It does not follow from the current insufficient transparency of our
> elections systems that we should accept this lack of transparency in
> the future.

I agree with that point.

What I was trying to illustrate is that, when you rely on a perfect
chain of custody, there is no way to be fully transparent. There are
ways to be more transparent than, say, the current Boston procedures, of
course, as you correctly point out.

But there remain some intractabilities: somehow, the ballot boxes have
to be transported. Somehow, the ballots have to be handled for counting.
You can't always expect every observer to see the entire chain of
custody. One inconsistency (ballots destroyed, ballots stuffed, etc..),
and the rest of the auditing becomes useless.

There are inherent limitations to verifiability when you have the secret
ballot... limitations that, as far as we know, can only be overcome with
 techniques from cryptography.


> Please correct me if I'm wrong, but as I see it, in order for your
> cryptographic system to be verifiably correct by the technically able,
> it would require that:
> 1. all its software be open source, and

actually, no, the software doesn't need to be open-source. (Though I
love open-source and I favor it wherever possible.) The software
provides a *proof* that it did its work correctly, so you don't need to
look at its source code.

The software that *verifies* this proof can be written by anyone, so
while it's nice to have an open-source version of it lying around,
that's not necessary: any programmer could re-create it easily. You
would expect political organizations like the ACLU to write their own
and publish it as open-source, of course, but that's secondary to the
core idea.


> Do you agree that your system, to be transparent to the technically
> able, needs to be open source, or at least publicly disclosed?

Again, though I strongly support open-source, that is technically not a
requirement for open-audit systems. I'm hammering this point in because
I think most people don't understand open-audit voting: they think it's
just normal voting with a bunch of crypto thrown in, and the crypto
doesn't add anything.

This specific property, that you can audit the results without auditing
the equipment---which is surprising!--- is the crux of the issue.

Let me repeat this: in an open-audit voting system, you get full
transparency even if the source code is not revealed. That's because
you're relying on the mathematical proof produced by the software, which
it cannot fake any more than it can draw a right triangle whose
dimensions violate the Pythagorean theorem.

Another way to see it: open-audit voting systems are
software-INdependent. They use software, but they don't depend on its


> In our proposals, we define
> Transparent: means that an average non-technical citizen can observe
> and fully understand the procedures, well enough to determine if they
> are being done honestly and properly

In that case, I argue that this definition is wrong.

Maybe you mean "accessible to the layman," which is a perfectly arguable
point. However, by using the words "transparent" and "complex"
interchangeably, you're misleading folks into thinking that making a
system simple is the same as making it auditable.

We need to differentiate the two aspects, especially since complexity is
 in the eye of the beholder, while transparency can be measured fairly
objectively: what kind of special privileged access, if any, do I need
to be able to directly audit? In open-audit systems, the answer is "none."

> As you know, opscan paper ballots can be manual counted

Assuming this could be done reliably (the Caltech/MIT report says it
can't), this wouldn't change the problem of a broken chain of custody
sometime before the counting.

How can something be transparent if I can't ride in the transport
vehicle that takes a ballot box from one location to another? How can I
be sure that the software on the optical scanning machine wasn't
modified between the open-source audit and the actual election (see the
UConn VoTeR report from last month regarding the 5-minute compromise of
an opscan machine)? How can I be sure that there weren't extra ballots
in the box when the voting day began? I have to trust *someone* that
this was done correctly. That's not transparent, because no matter what,
I can't verify everything directly.

All of your proposals attempt to minimize these problems, and I fully
support these efforts. But we have to realize that this doesn't change
the basic nature of classic voting systems: there's a chain of custody
to maintain, and even a single failure can lead to a corrupt election
result. Thus, there's a transparency ceiling.... unless you resort to
open-audit techniques.


>> Then take typical DREs (without paper or crypto trail.) They are
>> *really* simple to use. When they don't fail, voters love them. But we
>> know how opaque they actually are. So self-evidence again fails us here.
> Yes, so what's your point? Are you saying that because we have a bad
> system now (with both optical scan and DRE voting systems), that we
> should accept keeping a certain amount of opaqueness in our election
> system?

Not at all.

My point is that, if we listened to "most voters," DREs would be here to
stay. It's the activists and folks like OVC that have brought to light
the issues with current systems. And folks on this mailing list are
certainly "experts" compared to average voters.

In other words, self-evidence is a *really* bad measure of what makes
for a secure election. If that's the yardstick, then we're putting
perception above reality. Perception is important, but it's not sufficient.

> Don't you mean "anyone" with the technical capacity can audit; and
> that anyone without the technical capacity should "trust" those who do
> have the technical capacities to do it for them?

Yes, but that's the case with your proposal, too. Not everyone gets
statistics -- in fact I'd say that if you understand statistics, you're
not far off from understanding the crypto with a bit of reading. Voters
still have to trust *some* expert. In open-audit schemes, you get to
pick that expert, not from a pool of pre-approved folks, but from the
pool of *anyone* who is willing to read and understand the published

That's the key advantage of open-audit elections.


> If what is audited is the paper ballots, I don't see how paper ballots
> are "still running".

The processes surrounding the handling of the paper ballots, their
transportation, etc... that's what still needs to be audited. As you
mention below, voter fraud is still quite rampant with paper ballots.

> You are right that chain of custody, good election procedures,
> detailed record keeping, ballot reconcilation, and public access to
> all election records is necessary, I agree. There are many ways to
> tamper with paper ballots - stuffing, absconding, substitution, and
> tampering - and all of them occur with regularity today in America,
> which is why a mixed system of electronic and hand counts can probably
> detect and prevent the most types of vote miscount and fraud.

So that's a very good reason to explore the kind of system that OVC has
been proposing to date, to minimize the possible breaks in the chain of
custody. But is that the only direction we should be thinking about?

I'm asking the following question: are folks with OVC also willing to
explore open-audit solutions that *don't* require the perfect
maintenance of a chain of custody, and that provide a much higher level
of auditability? There may be some unfamiliar complexity involved, but
it's all published and available for anyone to review.

> Recent polls have shown that most voters would probably not be willing
> to "trust a mechanic" to tell them that their votes were counted
> correctly, nor do I see why any voting system makes sense that is
> susceptible to disenfranchising voters in the case of power outages,
> electronic failures, programming errors, ballot definition errors, or
> long lines and that cost much more than optical scan paper ballot
> systems.

Opscans have electronic failures and programming errors, too.

Open-audit systems actually do not suffer from programming errors,
because these show up immediately if an incorrect proof is provided.
Certainly, though, there's the chance of a massive electronics failure,
which is why you'd want backup machines, just like for the opscan solution.


> i.e. Why would any able-bodied voter need to have a computer to cast a
> vote every one or two years?

The use of a computer is not gratuitous, it's for a very specific
purpose: providing much better auditability. I'm not proposing
technology for technology's sake, I'm proposing that we consider much
better auditability, in exchange for some complexity, though that
complexity is almost certainly minimized by the fact that anyone willing
to learn the system can audit it.

So I'm hoping that this group is willing to consider this issue.
Importantly, I'm not asking for a blank check here: open-audit systems
need to be specified, analyzed, explained, and framed in a set of
recommendations, much like the work currently being done for
non-open-audit systems. It's just a question of whether folks are
interested in exploring, or if the decision has already been made that
open-source + paper is the only way.


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:11 2006

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