Re: Initial thoughts on technical design

From: David Mertz, Ph_dot_D_dot_ <voting-project_at_gnosis_dot_cx>
Date: Wed Jul 30 2003 - 15:30:44 CDT

"Douglas W. Jones" <> wrote
|In terms of methodology for this kind of things, first you
|design the system for functionality, then you identify
|the objects (both code and data) that must interact in the
|system, do a threat analysis, and then install appropriate
|additional fields (keys, checksums) and appropriate filters
|(encrypt, compute checksum, etc).

I disagree with Douglas here. I may well have missed aspects of the
threat model, or have cryptographic weaknesses in my suggestion. But I
strongly believe that this sort of design absolutely must come BEFORE
you design code, data, and interfaces. Security isn't something to bolt
on at the end; at least not if you do it right (i.e., not MS-style).

Moreover, what I suggested really has nothing to do with the code
involved. Even where I illustrate with some specific familiar
algorithms (SHA, AES), those are merely meant to clarify the style of
technique used at the stages, not commit to specific algorithms. The
overall protocol I propose isn't really about computers at all--it's
about voting. What do you need to do to add integrity constraints to
ballots? Never mind things like programming languages, data formats,
etc., which are secondary.

Alan Dechert wrote:
|A lot of this has been discussed. However, there is a good point here,
|namely, that a lot of it is scattered about.

That's good. Congealing it is probably an important early step.

|I have proposed each machine have a one digit number (combined with state,
|county, and precinct, this number would be unique). The ballot number would
|be a concatenation of the PC number and a random 3-digit number.

This is exactly the same as what I called MACHINE-ID and SESSION-ID.
It's good we're on the same page here.

|> 6. When the voting period ends, the machine is "finalized", which
|> discloses the private key, priv. At this point priv is public
|> information--it can be published in a newspaper or generally
|> circulated. One private key is disclosed per machine per voting
|> period.

|I'm not sure about this. The voter goes to the machine anonymously. The
|ballot number cannot be tied in any way to a specific voter except that the
|voter sees it.

This should not compromise voter anonymity, as I understand it. The
private key is generated for the machine (for the day), not for the
voter. However, to avoid storing any correlative information, a voter
would have to be free to choose whichever open machine she wished (and
such info would not be recorded by poll workers). This is largely the
same concern as the way timestamps could compromise anonymity.

Of course, even if it was covertly determined that voter Alice used
machine 1 (e.g. a secret camera in the polling place lobby), that would
only partition the final ballots. Mallory, in this case, can tell that
Alice used machine 1, and that a certain, e.g., 1/4 of the votes were
cast on machine 1; but it doesn't indicate how Alice herself voted. But
for a polling place with only dozens of votes cast, this might still be
too much information to leak.

I believe the private key aspect was not previously included in the idea
Alan mentioned. The goal here is to provide a much better integrity
check on a ballot than a simple redundant barcode could enable. Forging
something printed on a standard laser printer does not strike me as all
the difficult if such digital signature technique is not used.

Yours, David...

- --
  mertz@ _/_/_/_/_/_/_/ THIS MESSAGE WAS BROUGHT TO YOU BY:_/_/_/_/ v i
gnosis _/_/ Postmodern Enterprises _/_/ s r
.cx _/_/ MAKERS OF CHAOS.... _/_/ i u
       _/_/_/_/_/ LOOK FOR IT IN A NEIGHBORHOOD NEAR YOU_/_/_/_/_/ g s
Received on Wed, 30 Jul 2003 16:30:44 -0400

This archive was generated by hypermail 2.1.8 : Wed Aug 06 2003 - 12:50:26 CDT