Re: securing electronic ballots

From: David Mertz <voting-project_at_gnosis_dot_cx>
Date: Mon Nov 24 2003 - 10:55:10 CST

Hi Amit,

First thing, welcome to the EVM2003 project. It's good to have you on
board.

|I have not yet had a chance to review the proposed security scheme in the
|NSF proposal, but for sake of timeliness, let me add my thoughts to this
|thread:

Just to clarify, the NSF proposal (on which I am just an "outside
consultant", by no means a co-PI) does not advance my particular
protocol, described at:

  http://gnosis.python-hosting.com/voting-project/initial-digests/0109.html

Rather, the proposal just had some generic language like "analyze the
threat model"... I think written by Doug Jones (but apologies to a
different proposal author if one of the others wrote the paragraph).

|Using public-key signature schemes is indeed far preferable to using
|private-key crypto in this situation. Public keys have many advantages:

Not necessarily. AES, for example, has some very well understood and
well studied properties. To my mind, RSA--or even el Gamal--are still
potentially vulnerable to advances in number theory.

Moreover, an important principle in cryptography--and in a lot of
places--is to use "the simplest thing that can possibly work."
Symmetric encryption, in my mind and in most people's, is -simpler- than
is public-key cryptography (and cryptographic hashes are "simpler" than
symmetric encryption). Each step to a slightly more complex building
block takes a modicum of justification.

|1) One can immediately assess the validity of any ballot.

It is not clear at this point that this is even a good thing; and
certainly not that it is an actual criterion.

I can certainly see plausible arguments why we would want to enable a
"spot check" of ballot validity prior to close of a voting period. But
it's premature to declare that a design principle. I can also see a
counter argument that encouraging such spot checks weakens the existing
physical security of sealed ballot boxes (by letting checkers open them
to perform crypto).

|2) (Assuming the private key is destroyed) There is no risk of an
|adversary being able to produce false ballots at any time, including
|after the election.

Publication of all ballots at time T can also be used to declare
presumptorily invalid any ballot not published by time T. There's no
need to solve problems that we do not actually have.

But again, I'm not trying to forclose this, just saying that the real
threat analysis is yet-to-come.

|> P.S. In any case, even I admit the cryptography is somewhat secondary.
|This is a dangerous point of view. Having paper ballot printouts doesn't
|address the issue of ballot-stuffing, among others.

It's easy to focus excessively on algorithms when you look, from a
CS/math perspective, at the security of implemented real-world systems.
Real breaks are only rarely mathematical, "social factors" are usually
central. Don't discount the systems of physical monitoring and
procedures that have evolved over a few hundred years... also don't
accept them uncritically, of course! (lots of real problems have
occurred).

But since you're a new member, Amit, let me give a little context of our
brief development process. I proposed the referenced protocol pretty
much right when the whole thing started--probably coming in with much
the same attitude you have. Cryptographic verification can indeed be
quite useful for checks against ballot-stuffing, and I still certainly
want it for a production system.

But I have been persuaded by Doug Jones and others that it is not
necessary to include cryptographic signatures for the demo. Part is the
simple politics of the matter. The people we want to demo to are not
cryptographers. I still think we should let them know that these issues
are being addressed (and I still would want placeholder codes on
ballots, although I think that won't be in place either); but elections
officers are not going to think through the merits of SHA, RSA, AES, key
lengths, etc., at least not the initial ones.

Moreover, even raising the issue of ballot-stuffing is only a first pass
at a threat model. For example, none of these crypto codes address the
malicious or accidental -destruction- of valid ballots. Ballot
validity, however, *IS* being addressed in an OK way for the demo, by
utilizing watermark images with variable placement (tied to the
precint/machine, so pre-printed false ballots are visually
recognizable). Whether or not that is in the final system, I don't
know... but it shows to politicos that we are considering the right
issues.

Yours, David...

--
Keeping medicines from the bloodstreams of the sick; food from the bellies
of the hungry; books from the hands of the uneducated; technology from the
underdeveloped; and putting advocates of freedom in prisons.  Intellectual
property is to the 21st century what the slave trade was to the 16th.
==================================================================
= 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