Re: Critical analysis of VoteHere

From: charlie strauss <cems_at_earthlink_dot_net>
Date: Sun Dec 14 2003 - 19:11:14 CST

Ah good at last we are on the same page! I fully agree arthur. And
its comments like your last one I was interested in hearing. as well as
whether the votehere actually can work.

On Dec 14, 2003, at 5:43 PM, Arthur Keller wrote:

> 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