FW: Not your ordinary barcode

From: Popkin, Laird (WMG Corp) <"Popkin,>
Date: Mon Apr 19 2004 - 12:05:18 CDT

A question from a friend:
-----Original Message-----
From: Eric Lazarus [mailto:eric_dot_lazarus_at_decisionsmith_dot_com]
Sent: Monday, April 19, 2004 12:53 PM
To: 'Popkin, Laird (WMG Corp)'
Subject: RE: Not your ordinary barcode

Why can't the BPD computer basically fill in a pre-printed, numbered,
polling-place counted, human readable ballot? That's the quesiton that my
secuirty expert friend RB asks. It should just draw the same lines that a
human could draw between candidate on one side and office on the other. We
could use existing systems to read such ballots.

-----Original Message-----
From: Popkin, Laird (WMG Corp) [mailto:Laird.Popkin@wmg.com]
Sent: Monday, April 19, 2004 12:54 PM
To: Eric Lazarus (E-mail)
Subject: FW: [voting-project] Not your ordinary barcode


-----Original Message-----
From: owner-voting-project@afterburner.sonic.net
[ mailto:owner-voting-project@afterburner.sonic.net
<mailto:owner-voting-project@afterburner.sonic.net> ]On Behalf Of David
Sent: Monday, April 19, 2004 12:16 PM
To: voting-project@lists.sonic.net
Subject: Re: [voting-project] Not your ordinary barcode

There are a large number of security protections overlooked by Cushman
that are already part of the OVC system (either coded, or at least
specified as needed for production). Our design assumes both malice
and incompetence by everyone involved in every stage, and produces a
system to deal with those assumptions. :-)

(1) On substituting a "special" but disguised barcode format: Code128
is interpreted at the hardware level (well, scanner firmware). The
only thing any software application sees is a string of numbers. So
it's these numbers that would have to have special properties. An
attack at this level would have to bribe EVERY scanner manufacturer
(since we do not specify in advance a particular maker).

(2) The encoding of votes->numbers is an open API, available for
inspection by any voter (or any non-voter too). OVC encourages
independent implementations to verify the votes/number mapping.
Contesting political parties can each develop their own verifier (or
you can check an individual one with pencil-and-paper: it's not a
difficult API, just a bit tedious to perform the basic arithmetic by

(3) Ballots WILL be spot-checked (or in case of a court challenge,
probably checked on every ballot) to assure accurate relation between
barcode and printed votes. The magic of statistics lets us catch
errors with confidence levels.

(4) Even the code our internal systems uses to scan barcodes for
vocalization or tallying will be (is) fully open. It might be possible
to stick in some subtle error that tallies wrong in some situation, but
wouldn't be noticed by casual code inspection. But it's certainly not
possible to stick in a whole ChangeElection() special function that
gets called in with particular input.

(5) Even subtle statistical errors in tallying can be caught by spot
checks and recounts (at least in principle). For example, if our
tallying software "loses" one vote out of 50 for the 6th position on
the ballot (the sort of error I can remotely imagine passing casual
code inspection), we can find that behaviorally in a manual recount.
The code to make, e.g. the Greens win by *exactly* 1% all the time,
regardless of real vote, cannot escape detection.

(6) Code is passed from coders fingers to voting machines using a
process of published hash sums and cryptographic signatures to insure
that the code certified is identical to the code running on machines.

Now obviously, if you posit a scenario where all the elections
officials in a district are in on the intention for fraud, and they all
decided that a certain party/candidate will win, OVC machines by
themselves aren't going to fix this. For OVC machines to work, you
have to assume a moderate level of oversight by disinterest parties, or
at least parties with competing interests. But that's not a problem
that *we* can solve.

Yours, David...

Dred Scott 1857; Santa Clara 1876; Plessy 1892;
Korematsu 1944; Eldred 2003

= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
Received on Fri Apr 30 23:17:13 2004

This archive was generated by hypermail 2.1.8 : Fri Apr 30 2004 - 23:17:29 CDT