Re: code validation?

From: Ron Crane <voting_at_lastland_dot_net>
Date: Tue Feb 22 2005 - 16:45:29 CST

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. And, given how the world works, this fraud is
likely to be attributed to a "glitch" instead of being traced to its
root. As evidence for this phenomenon, we have, for example, a problem
in Ohio in which voting machines somehow enabled 600 voters to cast
4,000 votes for a particular presidential candidate, As far
as I know, this event has not been investigated.

We could partially brick up this rat-hole if our deployment procedure
required elections staffs to do the check build. But how many are
capable of doing that? And what if they did, and found a mismatch? Bear
in mind that they might be doing this only hours before the polls open.
Are they going to delay opening the polls until they get to the root of
the problem? I doubt it, even if that were legally permissible. They'll
just use the compromised code, and let someone (almost certainly
ineffectively) challenge the election results later.

We need a better procedure.


On Feb 22, 2005, at 2:05 PM, David Mertz wrote:

> On Feb 22, 2005, at 4:45 PM, Ron Crane wrote:
>> This means that we have to trust certain people in the "official
>> releasing authority", especially if portions of the executable code
>> base are built (e.g. compiled) from the publicly-revealed sources.
>> Let's say that someone associated with OVC wanted to add cheating
>> code. If the executable code were built from the sources, it would be
>> relatively simple for the cheater were she to become the "build
>> maven" or a sysadminThis is a strong argument for using only
>> interpreted languages (without self-modifying capabilities!)
> While I'm a big fan of -dynamic- languages (Python, Ruby, etc), as you
> can find in the archives, I don't want to push them based on false
> arguments. The solution to getting properly verified voting system
> code is a combination of open source and good crypto protocols
> (largely use of a strong hash). This isn't any different whether the
> OVC apps are coded in, e.g. Python, or in C.
> Let's say I wanted to insert malicious code (as someone quite
> plausible to have the role of "build maven", having been project lead
> for a while, and now being OVC CTO), what would happen? So I write
> the nasty code, simple enough.
> But here's the rub: to maintain transparency, OVC releases the
> complete code, including build scripts or instructions. I.e. (1)
> Here's the code; (2) It is compiled with MyLang compiler version 3.14,
> using switches -x -y -z; (3) The resultant executable is hashed using
> the widely available tool 'sha' and produces hash 0x1a3c245....
> In my power position I can easily release code X, while internally
> building with malicious code X'. But all those people out there who
> try compiling the released code (and they all have the Free Software
> MyLang-compile application) find that their hash doesn't match mine.
> So the word goes up that the current build is not to be trusted until
> matching code and hash are specified. If I release X', they many eyes
> will (hopefully) find my malicious modification (it still takes human
> examination, but I can't hide what I've done).
> The guiding principle of OVC is "trust no one"... not me, not Alan,
> not Arthur, not your own mother, etc. With transparency, everything
> we claim to be so can be independently verified. This includes that
> the right CD is actually delivered to polling places, the released
> code is that actually used to build the CDs, 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