Re: Critical analysis of VoteHere

From: charlie strauss <cems_at_earthlink_dot_net>
Date: Fri Dec 19 2003 - 18:55:24 CST

>The point of their voting receipt is to prove to the VOTER (not
>a 3rd party) that the voter's intent was captured correctly by
>the machine. This it manifestly does do. Of course, it does
>not prove that the votes are later counted correctly.

Actually this is not so. The intent of the vote here is to assure the voter his vote WAS counted as cast after they have gone home from the polls. In fact this seems to be the whole selling point that distinguishes it and chaums method from other verifcation schema. This is bit worrying because they are introducing this new desiderata "count-as-cast" that conventional paper ballots lack. Paper ballots achieve this through observers and procedural safe guards. OVC is nice because it adds one more observer: the computer count must reconcile with the paper.

The Vote here scheme does not need these procedural safe guards at vote counting time because the voter can (supposedly) verify his vote made it all the way to city hall and was counted in the final tally. However when you break down the mechanism Votehere uses to achieve this ability it appears that in the end they too ultimately hang on a set of precedural safeguards. The are different procedures and occur at a different point in the voting process but never the less the safegaurds at some point become procedural. Thus in the end it cannot be said to escape the possibilty your vote was not counted afterall.

there are thus two distictions: the vote here scheme could fail catastrohpically system wide, whereas and paper ballot hanky panky is going to come from localized conspiracies. Second there is no sunshine and hence voter trust in the procedures used to create the assurances your vote is counted. this last one is the nail in the coffin for me.

>It is also true that with paper ballot images, you can have a
>meaningful recount (under the assumption that none of the paper
>ballots have been lost). It is also true that with the VoteHere
>system, you cannot use the receipts for any kind of meaningful
>recount, and they do not claim that.

right while the vote here system offeres many points where vote problems can be detected it fails to offere a way to gracefully recover from such a problem> there is no way to recover from a problem. Nothing to recount.

>Instead, VoteHere actually
>has a much stronger system than recounts for backend processing
>of ballots, namely, the production of a formal,
>cryptographic-based, mathematical proof that no ballots have
>been lost, forged, or added incorrectly, a concept that has no
>analog in the paper world. This formal proof can be published
>on the Web, and is checkable by anyone, and indeed one can
>imagine the Democrats, Republicans, and Communists all hiring
>their own experts to write proof-checkers (a simple task) so
>they do not have to believe each other's (or the government's)
>proof checker.

Really? that's what they say it does. But frankly I cant quite follow their explanations in the white papers to vverify that it actually acheives this. I think I spot multiple holes in fact but cannt say for sure because maybe I have a wek understanding. This is in fact why I created this thread. If you can explain how this is acheived in clear detail I strongly urge you to post it here and let us insert comments so we can come to a concrete appreciation of the methods strengths.

>This proof is irrefutable;

I'd say it's not as above. I'll just pop in with problem. Unless the machine prints out the name-to-number mapping (on a separate paper receipt) then I dont see how the back end encrption proves this was not switched in the machine. They claim for example that because the machine gives your the "receipt" before you confirm it cant know how you will vote for sure. Uh nonsense. Just swap the numbers for the stonger polling candidate and the weaker and you will make the weaker one win even if you dont know the individual voters committed choice. He might catch the switch but could never prove it was not his own mistake.

>it is far stronger basis for the
>claim that the election is OK than any recount, since counting
>is frought with opportunities for error, whether done by machine
>or human. Remember, there is nothing that can be done about a
>lost paper ballot, and no recount can fix it.

one lost paper ballot is one lost vote, and unless deliberate will be a random event. In votehere you could have millions of systematically lost votes due to computer "glitch" and no way to recover. You might detect there was aproblem but you cant recover; there is nothing to recount.

>I have no connection with VoteHere, and am not promoting their
>products. But I do know them and their work, and I don't think
>they can be easily dismissed.

I dont think it can be dismissed either. Some OVC people do seem to dismiss it, and I agree that is disturbing. But is also important not to swallow votehere's claim their ssytem is "provable" till it is proven. and more imporantly its important not to up the ante to "counted-as-cast" when that is not required and would essentially put all paper ballot based system out of bussiness.

>They are, as I said before, the
>only "vendor" doing original research in voting system security,
>and they do know what they are doing.
>My point is not that the VoteHere system is "better" than the
>paper ballot system.

Lack of voter trust, lack of proof it works, lack of recoverability in a problem, will geriatric poll workers maintin the required safe guards, will idiot elected election officials maintainthe correct computer security, where is the sunshine that assures the procedural safe guards. the thing about OVC is that while its a tad clumsy and low tech any idoit can tranparenty see it will work and restores traditionally accepted ballot counting methods to computer-enabled voting systems. You can if youre patient explain it to your grandma. Any mortal can try to poke holes in it and find they cant.

furthermore what happens if something does go wrong and the decrypt key is leaked or stolen, even a year later? then secret balloting is history. The decrypt key does not actually have to be stolen for this to true; just the threat it could be is sufficient intimidation. Additionally Wont the decrypt key have to be revealed in any challenged election? Finally, as david mertz points out, a cel-phone cam image of the screen would allow decryption of the receipt.

>(It certainly is not understandable in all
detail to non-cryptographers.)

I certainly have some experienc ein cryptography and the scientific mathematical background to understand most journal article on it with at least modest comprehnsion if not detail in proof, and frankly I dont understand their system wel enough given their white papers.

I just think that it should be
criticised with full knowledge of the system and the rationale
behind it.

David

--- Edward Cherlin <edward.cherlin@etssg.com> wrote:
> On Wednesday 17 December 2003 06:38 pm, Clay Lenhart wrote:
> > On Sun, 2003-12-14 at 19:43, Arthur Keller wrote:
> > > 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.
> >
> > I agree too, that receipts are not very useful.
>
> Receipts make secret voting impossible, as discussed on
> another
> thread recently.
>
> > The
> > verification *data* (the reciepts) is dispersed among
> millions
> > of people. It would be difficult to prove that something
> > might be wrong with the electronic copies to force a count
> of
> > the real (paper) ballots since a group of lawyers would not
> > have all the verification data in their hands to prove the
> > electronic ballots are wrong. The receipts only give a warm
> > and fuzzy feeling for voters,
>
> Except those under some compulsion to prove how they voted.
>
> > but do not prove that their
> > ballot was counted -- just that their ballot is in a pool of
> > ballots *claimed* to be counted correctly. It also does not
> > detect if extra illegal electronic ballots are in the pool
> of
> > ballots.
> >
> > It would be better to have all verification data accessible.
>
> > To give an example, if the electronic ballots are signed
> with
> > public/private keys, then the public keys, signatures and
> > ballots would be available for anyone to download, verify
> the
> > signatures, and count the ballots themselves*.
> >
> > Having voter-verified receipts is not bad, just less useful
> > than verification schemes that can verify the *whole*
> process.
> > If they can be included without conflicts, sure.
> >
> > -Clay
> >
> > * The simple pub/priv key scheme is not very good: it
> doesn't
> > detect inserts or deletes, but you could add to the
> > verification data a signed list of ballot numbers printed by
> > the voting machine -- but then you have the paper jam issue
> > where you will have signed ballot numbers but the ballots
> > legitimately should not be in the count.
>
> Sign a digest of the scanned and verified ballots. This has
> been
> discussed in another thread.
> --
> Edward Cherlin, Simputer Evangelist
> Encore Technologies (S) Pte. Ltd.
> Computers for all of us
> http://www.simputerland.com, http://cherlin.blogspot.com
==================================================================
= 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:15 2003

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