Re: Critical analysis of VoteHere

From: Arthur Keller <arthur_at_kellers_dot_org>
Date: Sun Dec 14 2003 - 18:43:16 CST

At 5:03 PM -0700 12/14/03, charlie strauss wrote:
>On Dec 14, 2003, at 2:29 PM, Arthur Keller wrote:
>
>>At 11:42 AM -0700 12/14/03, charlie strauss wrote:
>>>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.
>>
>>And why can't someone else call in with your receipt, just like you
>>can? There must be a way for the end-voter to verify what "56"
>>meant for his/her own ballot.
>
>No that's exactly the point. Not one including you can learn any
>more than you voted for 56. There is no way for anyone besides the
>election judges to know what 56 means. the connection between 56
>and who you voted for is revealed only to you at the time you place
>your vote and its escrowed in encrypted format by the election
>computer at city hall. When you call in you are ONLY verifying
>that your vote made it to city hall without modification. You are
>not checking to see if 56 means joe blow--thats taken care of by
>that escrowed mapping that city hall has. At that point the only
>way your vote can be monkied with is if the escrowed mapping got
>messed with. Which might be a danger or it might not be; I'm not
>certian votehere's procedures are good enough.
>
>One can however imagine that the mapping could get leaked some how.
>its in the voting machines, the election judges have a book with it
>in it, and its at city hall. I think you could get someone to leak
>a copy. then the receipts could be connected to votes. Moreover,
>just the threat to a leak might be sufficient for coercion (though
>not for vote buying).

I wouldn't call that a voter-verified receipt, since I can't tell
from the receipt if the machine switched my votes. The scheme,
however clever, won't make the average Joe feel more secure. In
fact, it is likely to cause an uproar of confusion. FUD will defeat
adoption of this scheme, as in, what problem does it solve? The
level of understanding required to realize the problems being solved
are beyond most decision makers. And the clamor for a voter-verified
receipt won't be satisfied by this random piece of paper.

What happens when one husband and wife, who always vote the same
because they decide their votes together, compare their receipt and
find---horrors!---that their votes don't match! Imagine their outcry
about those computers messing up the tally.

>>>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.

This may indeed be a problem, but we'll never get there, because the
"ordinary human" testing, which I assume many jurisdictions will do,
will fail.

>>>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.

One lesson we have to learn from the outcry of DREs is the process
must not only be correct and armored against attack, but it must
*appear* invulnerable to attack. The use of computers initially gave
people a warm fuzzy feeling that was lost once people realized how
badly the software was implemented. If the voter can't personally
verify the receipt, then the benefit of a voter-verifiable receipt is
lost.

That's why we need to have an FAQ, as I have proposed, on the
differences between a voter-verified RECEIPT and a voter-verified
BALLOT. Even a receipt does NOT ensure that the vote recorded in the
computer is correct, and it does not ensure the ability to do manual
recounts. Only voter verified BALLOTS do that. This is, in fact, a
most important lesson from our demo, a point we need to make loud and
clear. It is an important distinguishing factor between us and DREs
with printers. Unless the receipts are themselves counted, the
computer could print what the user wanted and the user's ballot
recorded on the computer could still be wrong.

It would be nice to have a separate PC programmed like all the other
machines, except that it fudges the votes: it prints the correct
receipt (but NOT a ballot), and it displays on a screen after
printing the receipt the actual votes it is recording (which are
different 10% of the time in a particular biased direction). Such a
process would bring our point home clearly. Let the person who
writes the code for changing the vote use an obscure process that
doesn't make it obvious the vote is being changed. For example,
initialize the recording area to all "1"s (where "1" is a valid vote
you want to have voted extra). Then for every ballot, move the
selections from the work area to the recording area, but
occasionally, the pointers and lengths get messed up (the intentional
"bug"), so the first vote doesn't get copied over (and is the
pre-initialized value), and one fewer vote gets copied over. For
example, if there are 10 races, and usually you copy races 1 to 10,
the "bug" is to copy races 2 through 10 instead. (Maybe we should
program it so when a particular vote is made for a down ballot race,
the "bug" gets tickled, so we can deliberately demonstrate the
problem when we want to. This is the kind of demo that can get us on
the national news, particularly when coupled with "doing it right."

I think we want to cast down on voter receipts, and this is the way to do it!

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:12 2003

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