Re: open-audit elections

From: Ronald Crane <voting_at_lastland_dot_net>
Date: Tue Dec 12 2006 - 23:59:22 CST

> > 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
> correctness.

But this isn't quite so. Let's assume, for the sake of argument, that these
systems allow a voter to determine whether her ballot was counted as cast
without being able to prove its contents to anyone else [1]. Even so, these
systems still act as intermediaries between a voter and a presentation of the
ballot. They are, therefore, capable of manipulating the presentation so as to
influence, deceive, or even force the voter into choosing a candidate whom she
would not, absent the attack, have chosen. For example, an attacker might
program the system to omit a candidate from the ballot, to reorder the ballot,
or to make a candidate difficult to select. Because this kind of attack can
affect the votes a voter actually casts, it bypasses audits aimed at
determining whether votes are counted as cast.

All computational intermediaries are susceptible to this attack. Heck, even
computer-printed paper ballots are, but that susceptibility is very limited
because ballots are immutable once printed. Therefore they can be audited
before use to minimize the probability of an undetected attack. This doesn't
work with computational intermediaries because their presentations are mutable.

> > 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?

I don't accept that definition because it does not account for the level of
trust the voter must place in the experts who tell her how to audit the system.

> In open-audit systems, the answer is "none."

That's not quite so. You need access to the appropriate experts who can tell
you whether the system you're attempting to audit actually can effectively be
audited using the prescribed procedures. Now this is also, to an extent, true
of sampling hand audits of machine-counted hand-filled paper ballots. But the
level of expertise needed to verify the correctness of a cryptographic voting
system is much higher than that needed to verify the correctness of random
sampling hand audits. Consequently, the public is forced to trust a much
smaller pool of experts for the former than for the latter. That also means
that an attacker (or a tyrannical government in the making) need corrupt (or
coerce) a much smaller pool of experts for the former than for the latter.
That's a weakness.
> > 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.

There is always, somewhere, a trust problem for real elections. I would like
to minimize it by making it as easy as possible for ordinary citizens, with
minimal or no expert input, to use their native intelligence and common sense
effectively to audit their elections. Paper systems come much closer to
allowing this than do crypto systems.
> Open-audit systems actually do not suffer from programming errors,
> because these show up immediately if an incorrect proof is provided.

This overstates the case. Aside from the presentation attacks I discussed
above (or errors that act like them), an attacker might resort to
delay-of-service and denial-of-service attacks to selectively disenfranchise
certain voters by creating unacceptable delays.


[1] I am not yet convinced that these systems provide this capability, but it
could be because I am only passingly-versed in cryptography. Someday soon I'll
revisit the VHTI paper and see whether I still hold the same views afterwards.
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