Re: Critical analysis of VoteHere

From: charlie strauss <cems_at_earthlink_dot_net>
Date: Sat Dec 13 2003 - 09:05:35 CST

Dennis et al,
I'm not advocating the Cotehere system but I do want to understand its
flaws. I can I think answer your questions.

Actually you have two questions, 1) how does the voter know his vote
was correctly recored if all he gets is a number. 2) how is a recount
done without a paper ballot.

answering the second question first:

The voteHere concept is that if any voter can be sure his ballot was
counted correctly then these is never any need for a recount. In
essence the recount is distributed to the voters themselves. If any
voter finds a single mistake then you know there is a problem.

--> and this I think demonstrates a weakness in the system. While it
detects when the electronic vote has been corrupted it does not allow
any way to correct a faulty vote by determining voter intent. The only
recourse I can see is to have a new vote if enough voters
complain--perhaps one should be enough. On the other hand paper
ballots schema could conceivably have a related problem if ballots
appeared to be missing, or if there were ballots in the ballot box that
had no counterpart in the computer log.

answering the second question:
Why upon hearing the numbers match should a voter trust his vote was
counted. The Votehere concept is that at each step where a switcheroo
could occur there is a high likelihood of detection. For example, as
long as the mapping of numbers to names is printed out on a separate
receipt that is kept at the polls then the kiosk cant switch the
mapping it displays without the the possibility the voter will notice.
Second If the kiosk printed out a fake mapping then this could be spot
checked later against the mapping that was published before the
election.

---> there are two weaknesses here. first the votehere scheme does not
actually call for printing out the mapping on separate receipt the
poter leaves at the polls. they dont really explain that weak point
well--they suggest on screen spot checks which dont work in my mind.
That was just my suggestion to show its not an insurrmountable problem.
    Second, there is no good explanation of how to check the mapping
against the published mapping. You cant just publish the mapping later
(decrypted) because then someone who had your receipt could determine
how you voted. Possibly some voting commission could be trusted to
decrypt it but not make it public when checking is needed.

On Dec 13, 2003, at 2:48 AM, Dennis wrote:

> Hi Charlie et al,
>
> I'm a bit confused. If I call up the 800 number and it spits out
> the code for Joe, how do I know that my vote was recorded for Joe
> and not Sam?
>
> In other words, is there a voter-verified paper ballot that can be
> used for a manual ballot recount as required in California? If not,
> their scheme fails the reliability test.
>
> In general, receipts are not required although if there was a way
> for voters to validate their votes from the county, it would be nice
> to be able to do that. However, the critical requirement is the
> availability to do the manual recount and that means a recount that
> is not dependent on a computer to interpret the voters' intent.
>
> Your description didn't explain how that is being done here.
>
> Dennis Paull
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> At 11:56 PM 12/12/2003 -0700, you wrote:
>> Has there been a critical analysis of the VoteHere technology on this
>> forum or published elsewhere? If so please point me to it so I dont
>> waste your time.
>>
>> Assuming there has not been I'd like to start a discussion on
>> VoteHere.
>>
>> the question is what are the problems with the VoteHere Scheme? So
>> far
>> I see two flaws but perhaps they can be remedied. It does add a layer
>> of complexity but it may not be too bad since it does not require that
>> every voter actually check their receipt just some.
>>
>> Here is a nutshell summary of how VoteHere Works for those that dont
>> know.
>>
>> PLEASE READ THIS ALL THE WAY THROUGH BEFORE YOU KNEE-JERK AND SAY THAT
>> "receipts don't work or allow coercion".
>>
>> After selecting his votes on the touch screen the voter is presented
>> with a final summary of his choices and a "cast ballot" button.
>> But BEFORE the voter presses this button he is also given a paper
>> receipt which shows his choices in an easy-to-read code. THe voter
>> will take home the receipt, the vote is recorded electronically after
>> being cast.
>>
>> When you were deciding who to vote for the ballot question looked like
>> this:
>> "who do you want for president?"
>> Joe Blow (56)
>> Sam Jones (63)
>> Hilbert Holler (13)
>>
>> Your final summary on screen looks like this:
>> Ballot ID: 5444321
>> president: 56 joe blow
>> senator: 32 jane doe
>> ...
>>
>> The receipt does not show the names just the numbers
>> Ballot ID: 5444321
>> president: 56
>> senator: 32
>>
>> Before pressing the "cast ballot" button, the voter can if he wants to
>> verify the numbers on screen and receipt match.
>>
>> The clever part here is that the relationships between the numbers and
>> the candidates names are different for every ballot. That for ballot
>> 5444321, joe blow corresonded to the number 56, but on ballot 544321
>> joe blow might correspond to, say 15.
>> thus by not knowing how the mapping was randomly chosen, no one can
>> know by looking at your receipt who you voted for.
>>
>> Now after the election is over, you decide you want to check your
>> ballot. You call the 800 number and punch in your ballot Id and it
>> gives you back the numbers and you can check them against your
>> receipt.
>> This way you know your ballot was counted as cast.
>>
>> the final ingredient is this. the actual mappings between candidate
>> names and numbers for each ballot is known by the election officers is
>> publicly published in an encrypted form before the election.
>>
>> --- that's mostly it---
>>
>>
>> So lets work a scenarios:
>> On the vote selection menu, the machine shows you that Joe Blow is
>> 56
>> and sam Jones is 63 before you have voted, so it might seem that
>> there
>> would be no incentive at this point to swap the numbers. (more on
>> this
>> momentarily).
>> At the summary screen, but before you cast the vote you can verify the
>> receipt matches the number. And the machine cant change your number
>> after your vote since it could get caught by your phone call later.
>>
>>
>> So are there flaws. I can think of two, but maybe there are more.
>> 1) suppose its known with virtual certainty that joe blow wil win.
>> Then if the machines simply swaps sam and joes numbers right from the
>> start then even though it does no know how an individual voter will
>> vote, it will reveres all the results giving Joes win to Sam.
>> Solutions: the mapping is also printed out on a separate receipt
>> for the voter to check but not take home. THe mapping could be
>> dropped
>> in a box for later spot checking by election officials.
>>
>> 2) How can you prove your receipt is a valid one. The votehere sytem
>> has the machine print a digital signature on the receipt to allow you
>> to prove the receiot is real. But suppose that when it wants to
>> change
>> your vote it simply munges the digital signature so that you cant
>> later
>> prove its a real receipt.
>> Solutions: well if a lot of munged receipts turn up you know
>> something is wrong. But you could also simply pre-print all the
>> receipts with a watermark and skip the digital signature.
>>
>> 3) one might complain that this code stuff causes headaches for the
>> voter. But to work not every voter has to check every vote. Just
>> some
>> spot checking by some voters is all that is required.
>>
>> their solutions to ballot stuffing is to publish the voter rolls.
>>
>> comments?
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
==================================================================
= 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:09 2003

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