Re: code validation?

From: Ron Crane <voting_at_lastland_dot_net>
Date: Tue Feb 22 2005 - 18:18:22 CST

There needs to be enough time between step 4 and holding the election
for the elections staff to get alternative code if the distribution
turns out to be compromised. Step 2a depends upon OVC being responsive
to the discovery of problems. This might not always be the case,
particularly if steps 1-2a do not occur sufficiently far in advance of
an election, or if the organization becomes infiltrated with cheating
operatives. The security of step 3 relies upon the security of
communications between trusted persons at OVC and the media; a cheater
there might attempt to publish the hash for her cheating code. Again,
this step has to occur sufficiently far in advance of an election for
any problems to be discovered.

Also, this approach assumes a community active enough to discover
problems or fraud. I love open source software, but many open source
projects languish after an initial burst of activity. How much of our
platform's security should we base upon the unknown quantity of
community participation?

End-to-end voter verification would add another layer of security to
this approach. EEVV has been raised by others, and criticized for its
susceptibility to vote-buying schemes, but I don't see that it's
susceptible to anything that absentee-ballot or mail-in-ballot
approaches (e.g. Oregon's) aren't. What I mean is generating a unique
vote id for every ballot cast, then publishing each ballot's selections
in the newspaper indexed by id. This allows anyone to tally the
election, thus helping to catch fraud anywhere in the voting system
itself. Like other voter verification approaches, it does depend upon a
statistically-significant number of voters verifying their ballots.
Also, it doesn't prevent a cheater from adding votes to the total,
unless elections officials check the total number of votes against the
number of voters signed in at each precinct.

How much security is enough, when the future of our republic is at


On Feb 22, 2005, at 3:03 PM, David Mertz wrote:

> On Feb 22, 2005, at 5:45 PM, Ron Crane wrote:
>> Unless "all those people out there" are able quickly to stop
>> elections officials from using the compromised code, their findings
>> are interesting, and meaningful for future elections, but are likely
>> to allow at least one fraudulent election to occur and its result to
>> be certified in the interim.
> No, no, no.
> Here's the steps.
> (1) Date 0: The OVC "build maven" releases code and build instructions
> to the wider software and elections community. This includes the
> instruction: "This code, when compiled/assembled/linked/processed
> should hash to ..."
> (2) Date 0-N: The community checks the "release candidate" code. Such
> checks include both the mechanical check of crypto stuff (hashes
> and/or other things, public-key etc.) and examination of the
> underlying code.
> (2a) Date 0-N: If problems are encountered (bugs, failed hashes,
> etc.), restart the process.
> (3) Date N+1: The hash codes for the final "this year's election" OVC
> code are published in the relevant newspapers, websites, etc.
> (4) Date N+M: Hold the election. Poll workers compare the hashes on
> the CDs they receive to those widely published and accepted by the
> community of evaluators[*].
> ---
> [*] The poll workers need to be trained to do something like the
> following:
> - Insert the CD into an independent, separate computer (i.e. not
> running the OVC CD itself).
> - Type something like 'sha voting-station' (or click on something to
> do the same thing).
> - Hold the local newspaper that pre-published the correct hash in
> their hand.
> - Look at the hash displayed on screen.
> - Make sure the newspaper looks like the screen.
> I don't think those steps are self-evident. But I think people can be
> reasonably trained to perform them, even non-technical people.
> ---
> Now sure... this doesn't mean nothing can possibly ever go wrong.
> Maybe a CD is switched or damaged on the way to a polling place,
> either inadvertently or through malice. Maybe the polling place burns
> down the night before the election. Maybe the hardware malfunctions.
> Etc.
> _______________________________________________
> OVC discuss mailing lists
> Send requests to subscribe or unsubscribe to

OVC discuss mailing lists
Send requests to subscribe or unsubscribe to
= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
Received on Sun Feb 27 17:17:10 2005

This archive was generated by hypermail 2.1.8 : Sun Feb 27 2005 - 17:17:13 CST