Re: Critical analysis of VoteHere

From: charlie strauss <cems_at_earthlink_dot_net>
Date: Sun Dec 14 2003 - 12:42:37 CST

On Dec 14, 2003, at 9:21 AM, Arthur Keller wrote:

> At 9:09 AM -0700 12/14/03, charlie strauss wrote:
>>> Another problem with the scheme is that someone can demand your
>>> receipt and using that find out exactly how you voted the same way
>>> that you do.
>>
>> No this would not work. The mapping of names-to-numbers changes for
>> every ballot, that's the cleverness of their scheme but it introduces
>> a whole new problem of how you assure that the mapping you are shown
>> does not get switched. The Votehere descritpion of how this is
>> handled gets quite elaborate and I'm not perfectly certain it
>> succeeds. Any time someone tells you in detail about the exponents
>> in their crytoscheme before they give you the basic flow of the
>> method you should hang onto your wallet.
>
> The same way that *you* verify your ballot is the same way that
> someone else with your receipt can find out how you voted.

No you are not quite getting how the votehere scheme functions. Some
one with your ballot sees what you see: that you voted for "56" for
president. Only you and the central computer know that 56 corresponds
to Joe Blow. When you call in to verify your ballot the machine tells
you that your vote was recorded for "56" like is says on your receipt.
   THus calling in only verifies that what you saw at the polls made it
all the way to city hall undistrurbed. So the real question with this
system is does city hall think that 56 corresponds to Joe Blow? And
that is why they have this (too) elaborate scheme of published but
encrypted mapping tables for maintaining the correspondence between 56
and joe blow for your ballot number. THe quesition is does their
scheme succeed as described or are there holes.

In the case of both paper ballots and electronic ballots procedureal
methods and designated observers are used to ensure the vulnerable
points of the process. We are very comfortable with how to do this
with paper ballots. OVC is cool because it uses this plus some
additional checks. Votehere has a scheme too which might possibly work
but its not familiar and we have to look harder for holes in it.

>
>>> That's the benefit of a voter-verified *ballot* that has to be
>>> handed in for it to count. The voter can verify it is correct, and
>>> the voter doesn't walk away with any receipt that displays the vote.
>>
>> The votehere scheme also appears to be a voter verifeable system as
>> well. But it uses receipts not ballots. and the receipt does not
>> display the votes that any ordinary person can read. Paper ballot
>> schemes use well understood procedural methods for gaurenteeing that
>> no one changes the ballots. the vote here scheme introduces a
>> different less familiar procedural channel to maintain the mapping
>> between your receipt and the vote. Is this other method trustable is
>> the essential question being asked here.
>
> A paper ballot based system has a well-understood process for recount.
> The votehere scheme apparently requires an elaborate process for
> recount, and that process is essentially the same as the original
> counting process. Ideally, there should be multiple counting
> (tabulation) processes that can be crosschecked for validation. It's
> not at all clear that this is the case for VoteHere. But our approach
> can crosscheck the electronic ballot against the paper ballot, and the
> paper ballot can be optically scanned for the barcode and counted by
> reading the printing on the ballot.
>
> Best regards,
> Arthur
>
> --
> -----------------------------------------------------------------------
> --------
> 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 Wed Dec 31 23:17:11 2003

This archive was generated by hypermail 2.1.8 : Wed Dec 31 2003 - 23:17:19 CST