Re: code validation?

From: David Mertz <voting-project_at_gnosis_dot_cx>
Date: Tue Feb 22 2005 - 20:52:37 CST

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.

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

> 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

> 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").

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