Re: securing electronic ballots

From: David Mertz <voting-project_at_gnosis_dot_cx>
Date: Mon Nov 24 2003 - 07:35:56 CST

Clay Lenhart <clay@lenharts.net> wrote:
|People who have access to the private signing keys cannot have access to
|the electronic ballots before the ballots are published.

Fair enough (except there is no distinction in my scheme between private
and public keys, since it uses symmetric encryption).

|The people who publish the public signing keys used in the election
|cannot be the people who publish the ballots.

I don't agree with this as a general principle. Sure, if just one
authority published both, this might hold. But in real elections,
neutral observers from competing parties monitor the process. For
example, if both the Democrats and Republicans simultaneously publish
ballots and keys, no compromise is involved.

Think of this concretely. At the end of the voting period, the paper
ballots need to be properly transported, stored, spot-checked, etc. All
this depends on physical oversight by competing parties. Likewise, the
electronic results are transmitted by similar procedures; e.g. written
to a CD, flash media, uploaded over an (encrypted) telephone link,
whatever. That transport and handling of electronic data must be
monitored by both/all parties.

For example, if the hidden key is prominently displayed during the
"finalize" cycle on a machine, the Dems, Repubs, Greens, etc. will all
scribble it down when it appears. And of course, the software itself
will write the correct key as part of writing the media or transport
channel.

|To address this, representatives from the various political parties on
|the ballot could "publish" (verify) the public keys on each machine.

I still cannot figure out where Clay has gotten the idea that I suggest
public key cryptography in the referenced post. He has made this same
incorrect assumption in a number of posts. What I proposed is strictly
a use of symmetric encryption.

Of course, it is perfectly well possible to setup the finalization
sequence on machines so that all the ballots are disclosed BEFORE the
hidden key is (as in, seconds or minutes earlier, not days). This has
the machine "commit" to the ballots before anyone sees a substitutable
key. I'm not sure it matters, given the physical procedures, but it is
something we could consider AFTER the demo is over.

|Publish the public keys when initializing the machines -- in case the
|machine crashes. This way the ballots that are already signed will have
|a cooresponding public key.

This isn't a bad modification of my idea. That is, it COULD use public
key cryptography, and disclose the public key at initialization. So the
public key is published before any votes are casts. During the
finalization procedure, the private key is permanently and irretrievably
erased. Any valid ballot must match against the public key published at
the beginning of the voting period (per voting machine).

Again, I'm not sure it has a real benefit, but it's not unreasonable to
consider in more detail... but again, this is for *AFTER* the demo. The
demo doesn't use any cryptographic verification, neither my proposal nor
anything else. And that's fine! Our NSF proposal includes real
analysis of threat models and the like; and for production, these kinds
of details can be addressed much more carefully.

Yours, David...

P.S. In any case, even I admit the cryptography is somewhat secondary.
In the case of a challenge, we will have the voter verified paper
ballots to allow a recount. No matter how corrupted the electronic
files may become (through software error or malice), the paper is still
there. I don't mind--in fact, I quite advocate--additional
cryptographic checks in the process. But the paper is the ultimate
guarantor.

--
    _/_/_/ THIS MESSAGE WAS BROUGHT TO YOU BY: Postmodern Enterprises _/_/_/
   _/_/    ~~~~~~~~~~~~~~~~~~~~[mertz@gnosis.cx]~~~~~~~~~~~~~~~~~~~~~  _/_/
  _/_/  The opinions expressed here must be those of my employer...   _/_/
 _/_/_/_/_/_/_/_/_/_/ Surely you don't think that *I* believe them!  _/_/
==================================================================
= The content of this message, with the exception of any external 
= quotations under fair use, are released to the Public Domain    
==================================================================
Received on Sun Nov 30 23:17:07 2003

This archive was generated by hypermail 2.1.8 : Sun Nov 30 2003 - 23:17:13 CST