Re: Alternatives to a single bar code

From: Arthur Keller <arthur_at_kellers_dot_org>
Date: Wed May 05 2004 - 13:14:05 CDT

At 1:31 PM -0400 5/5/04, David Mertz wrote:
>Arthur Keller wrote:
>>1. Will someone please describe the length of the bar code in bits
>>in components:
>>a. header info (including election date, machine number, ballot id, etc.)
>36 bits:
>We do NOT need to explicitly contain spelled out version of all
>associated information. Rather, a globally unique ID lets us look
>up the election data in an external database (and as a reference
>into a corresponding ballot-election.xml file).

It's not clear that it's sufficient to be able to look up the ID in
an external database. The unique ID should as much as possible be

>>b. votes
>< 80 bits:
>Or at least that is my current assumption, pending historical
>demonstration to the contrary.
>>c. 2 DSS blocks
>We don't need two distinct signature blocks. One doubly-signed
>block is fine. Actually, I don't even think we need
>doubly-signed... but maybe.
>I think a 48-64 bit signature is more than sufficient. Compromise
>of a key only affect ONE voting machine, so we only have to increase
>the forgery costs to make that too expensive. It's not like a
>global "the whole election" key, that would be worth much more to
>>d. end-to-end check-code
>A CRC-16 does what we need. This is SOLELY to protect against
>accidental data corruption. Some barcodes, like Code128, already
>contain their own error detection as well.
>However, we can probably eliminate this too, since a signature
>already provides error detection (if it doesn't match, it's time for
>manual examination anyway... even if the mismatch is just because of
>a smudged barcode).
>>e. ECC block
>Not needed. Error check is plenty to indicate fallback to manual
>examination of printed votes. In fact, if the ECC is needed, that
>indicates a situation where we should manually examine the ballot to
>look for what went wrong.
>>f. padding for obscuring
>Not needed. Obscuring the votes in a manner similar to the demo is plenty.

Doesn't the current technique involve padding or some sort, and
therefore take at least a little bit of space?

So pending elaboration of point (a) above, this adds up to:

36+80 (larger if self-delimiting)+48+16 = 180 bits (at the very least).

Of course, this doesn't handle IRV elections.

Does this reliably fit within 1-D barcodes?

Best regards,

Arthur M. Keller, Ph.D., 3881 Corina Way, Palo Alto, CA  94303-4507
tel +1(650)424-0202, fax +1(650)424-0424
= The content of this message, with the exception of any external 
= quotations under fair use, are released to the Public Domain    
Received on Mon May 31 23:17:16 2004

This archive was generated by hypermail 2.1.8 : Mon May 31 2004 - 23:18:15 CDT