Re: code validation?

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

I more or less buy what you're saying so far. But we need to document
the procedures thoroughly.

However, at the very end, you say, "but the whole "vote receipt" thing
is a very bad idea. It doesn't add to, but detract from, security."
Apparently this refers to the end-to-end voter verification ("EEVV")
idea (voter gets unique ballot id number, each ballot's contents are
printed in the newspaper indexed by id). If so, I don't understand it.
That approach only improves security by providing a check on the
performance of the entire voting system. In fact, if (a) enough voters
verified their votes in the newspaper; (b) the legal framework for
challenges were improved; and (c) elections staff verified that the
number of votes cast didn't exceed the total number of sign-ins in all
precincts, our worries about the voting system itself would be much
reduced, since we'd be checking its ultimate output. I do recognize
that EEVV open up opportunities for vote buying, but it's no worse in
that respect than existing absentee ballot systems or than Oregon's
statewide mail-in-ballot system. If the vote-buying impact of those
systems is acceptable, I don't see why the vote-buying impact of EEVV
shouldn't also be acceptable.

See also comments below.


> On Feb 22, 2005, at 7:18 PM, Ron Crane wrote:
>> 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.
> Agreed entirely!
> There are a lot of procedural steps that need to go along with the
> cryptographic ones. Crypto is a valuable tool in insuring system
> integrity, but it's not a magic wand that makes all the security
> issues go away. Things like chain of custody and compliance with
> mandated protocols still make a lot of difference.

There's a problem here. There must be a known set of vendors who have
earned trust via the review process you described. Let's posit that OVC
is the only such vendor initially, and that it falls down on its
responsibility. How would elections officials learn about this, and how
would they find a new trusted vendor? Isn't there a significant chance
that, should OVC fall down, at least one, and possibly several,
elections would elapse before a new trusted vendor became available?

>> Step 2a depends upon OVC being responsive to the discovery of
>> problems.
> Part of the advantage with Free Software (or Public Software, if that
> definition gets ironed out nicely) is that if OVC falls down on their
> responsibility, someone else is allowed to assume it. When I write
> 'OVC' in the steps, that's more a placeholder for 'someone who is
> acting in the public interest and with full transparency'.

We need to determine the appropriate lead time.

>> if steps 1-2a do not occur sufficiently far in advance of an election
> Exactly how far in advance is far enough is a good subject for
> legislation, or at least regulation. I don't have some mathematical
> proof that one month, or six months, or whatever, is the right amount
> of lead time.
> But failure to deliver the final software in time is just one of the
> conceivable supply problems. Maybe the hardware won't be ready and
> functional. Maybe the paper stock is delayed at the printer. Maybe
> the booths are damaged in transport. And so on. The best we can do
> is mandate time frames and procedures... that fact isn't specific to
> OVC's design--it applies just as well, in a general way, to mechanical
> systems, or optical scan ones, or paper-and-pencil ballots.
>> if the organization becomes infiltrated with cheating operatives.
> That part doesn't matter though. Well, it does; but it's checked.
> When the "release candidate" code is sent out, the Green, Republicans,
> Democrats, Libertarians, etc. all have a distinct interest in making
> sure it won't cheat them. So the Greens hire a code inspection team.
> And the Republicans hire a code inspection team. And so on. If any
> one of them raises an issue... well, exactly how it is handled should
> probably be specified in law. But generally, anything legitimate
> should be mandatory to deal with before certification for elections
> use.

This is interesting. What if a show-stopper problem is discovered close
to (or dreadfully on) election day? I'd hasten to add that this
sort of thing has been far from rare in voting system history.

>> 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.
> You're right about the advance notice. But there's no such single
> source vulnerability. The Democrats send a notice to their elections
> workers/monitors that says: "Make sure the hash code on the CDs you
> receive really are XYZ". And the Libertarians publish the hashes in
> _Reason_ magazine. And Move-On send out the hashes in their email
> newsletter. All of these interested parties independently establish
> the hash based on the accepted release candidate... there are no
> "slipstream" changes between the release candidate and the actual
> release (it's a "candidate" in the sense that real problems can be
> vetted; not in the some MS-like sense of "test our beta for us").

Yes, I think legislation may be required.

>> Also, this approach assumes a community active enough to discover
>> problems or fraud.
> Yes it does. But then, there are a lot of people to whom fair
> elections make a lot of difference... or at least elections that are
> not biased AGAINST their side. Then again, I'd be fully supportive of
> legislation that told SoS's to hire their own independent verification
> teams on salary. Maybe it could even come out of HAVA monies.
>> How much security is enough, when the future of our republic is at
>> stake?
> No amount is too much... but the whole "vote receipt" thing is a very
> bad idea. It doesn't add to, but detract from, security.
> _______________________________________________
> 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:11 2005

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