Re: open-audit elections

From: charlie strauss <cems_at_earthlink_dot_net>
Date: Wed Dec 13 2006 - 10:52:00 CST

-----Original Message-----
>From: Ben Adida <ben@eecs.harvard.edu>
>
>Charlie,
>
>The VoteHere documentation can be found at:
>http://votehere.com/documents.php

Yes those are no good. I read some much more specific description of it earlier but those all seem to have been pulled from the web site. The best they offer now is an analogy to lotto cards.

>> 1) How do we solve the key control issue? If the key leaks, or is
>> broken, anytime between now and infinity all the ballots can be
>> identified with individual voters. What's the design principle that
>> fixes this?
>
There is
>no single key. There are a dozen keys, each held by different parties:
>one by Democrats, one by Republicans, one by the Election Officials, and
>so on... You need *all* of them to be compromised before privacy is
>affected. Note that this does not involve generating a single key and then
>splitting it into pieces. Each party actually generates a key on its
>own, independently, so there is never, in a single physical location, a
>single key that, if compromised, could destroy the privacy of the election.
>

 First, from a crakcing perspecting the encrytion is an input-output transformation that is invertable. For example: two applications of a public key encrytption like RSA is still a single mapping that inprinciple canbe inverted in one step.

second, in the end it has to be unencrypted to be used. It would seem that at that point the receipts can be tied to ballots if the data is leaked.

third, at some point the mess has to be unencrypted and at that point you need all the keys.
the whole thing is in unencrypted and if the data is grabbed at that moment then it appears you have a problem.

fourth, from a practical perspective if every party is encoding the works with their own key then the every party also has the ability to accidentally lose their key and prevent the whole thing from working. One would have to invent some sort of elaborate redundant escrow process.

I fail to see how the key control problem has been solved.

>Note that, after the election, it is expected that the secret portion of
>the keys would be destroyed, leaving only the public portions for
>verifiability. You only need *one* of the keys to be appropriately
>destroyed to ensure that votes can no longer be decrypted.

That's not how votehere works. It requires decryption, so you can't discard the keys.

>
>> 2) How does the voter verify at the poll that his receipt is an
>> encoding of his chocies and not something else?. What happens when there's a misscan? does the votehere

>The key idea is that there is a short interaction between the machine
>and the user that yields a confirmation code next to the chosen
>candidate's name on the receipt.

"Short" is hardly the word for it. Yes I have read the preposterous rigamrol the VoteHERE scheme requires to try to prove to the voter the receipt is not rigged. Having the voter verify that the two letter codes next to the candidates he chose match between the on screen version and the printed one. I assume you realize that will be nearly cognitively impossible in practice. As Selkirk has shown voters can barely verify a regular ballot. Moreover voters will not understand it.

It also does not seem to fix the misscan problem.

>There's some math in there that means
>the machine can't cheat, or it will get caught by just running a simple
>verification program on the receipt (that anyone can write.)

If we wanted to leave it to verification programs to validate machines then why is it every single machine error known has happened on a system that passed all it's logic and accuracty test and software reviews.

>
>> 3) when the voter calls City hall and deterimes he receipt was
>> present, what exactly is that telling him? How does this prove his
>> ballot was counted or counted as cast?
>
>There's a long'ish unique code on your receipt, you ask if that code is
>present on the voting list. (Alternatively you can just give your name
>and have City Hall read off the number to you and you just check that it
>corresponds.)

Yes but all this proves is that the encoded ballot was transmitted. Just as the poll book proves I voted. And the total ballots proves they all arrived. But in the vote here process the receipt codes are severed from ballots before they are counted. At that point any different set of ballots could be substituted and no one could tell. the list of receipts does not prove my ballot was counted or counted as cast. All this does is move the point where cheating is easy from the distributed precincts where it's hard for one person to do a lot of damage, to the central count where one person could change then entire outcome. The same can be said for counting mistakes.

 there is infact no open audit whatsoever since there is zero connection between the published receipts and the actual vote counts. You can contrast this with Rivest's tripple ballot where the actual ballots not a hash are published. There one does have an open audit. (Rivest's method fails to be adequate for many other reasons).

_______________________________________________
OVC-discuss mailing list
OVC-discuss@listman.sonic.net
http://lists.sonic.net/mailman/listinfo/ovc-discuss
==================================================================
= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
==================================================================
Received on Sun Dec 31 23:17:12 2006

This archive was generated by hypermail 2.1.8 : Sun Dec 31 2006 - 23:17:16 CST