Re: Critical analysis of VoteHere

From: Alan Dechert <alan_at_openvotingconsortium_dot_org>
Date: Sat Dec 13 2003 - 18:49:27 CST

>
> I think this is PROBABLY a good idea. But I don't want OVC/EVM2003 to
> commit to it yet, not until the security document has more eyes on
> it--especially experienced ones like those of Amit and David Jefferson.
>
That's fine. It's just a proposal. The personal vote proof thing has been
something a lot of people have expressed a desire to have. If we can give
it to them without compromising the security of the system, we should
investigate whether or not we could give it to them.

> It is not entirely decided whether and when the XML ballot images will
> be disclosed; and therefore the merit of this browse-and-print
> capability is premature IMO.
>
Right. Some say the info should be encrypted, although there are no
relevant guidelines on this that I know of.

> A couple -potential- weaknesses jump out at me. These might well be
> answerable, but I'm not sure of the implications:
>
> (1) The FIRST voter at a polling place only has ONE archived ballot to
> choose from (and therefore, something printed is provably theirs rather
> than someone else's--maybe the guys with the brass knuckles make their
> demand of this first voter). And even during the early voting, the set
> of ballots to choose from is smaller than at the end of the day.
> Conceivably some statistical attack based on sampled coerced disclosure
> of printed ballots would allow overall coercion.
>
Maybe I didn't make this part clear. You only get to print the duplicate
ballot(s) after the polls close, the ballot reconciliation procedure
completed, the electronic files transmitted, the precinct tally posted, and
the real paper ballots sealed. All of this should take no more than 15 - 20
minutes after the polls close. Only then would all the xml files be loaded
onto all the voting machines.

This means that only the people that hang around until after the polls
close, or people that returned to the polls would be able to print the
copies. This means that some people won't be able to do it but there is no
problem with that. Only a small percentage need to verify their individual
ballot with the published ballots to get a good statistical level of
confidence. It means that a lot of people would be returning to the polling
place when the polls close but this is not bad either.

> (2) If the write-in candidates appear in the disclosed XML files, the
> Coercers could demand that a voter both vote a certain way on race A,
> and write-in a specific value "Foobar57" on race X (whose outcome
> Coercers are indifferent too). In other words, a voter is ordered to
> produce a printed ballot like (not for a specific ballot #, but for
> some ballot with commanded values):
>
That's a good point. Probably the xml files should be taken from the pile
created from the barcode scan. Probably the write-in names should be
suppressed in the published votes unless there is a significant percentage
of write-ins in any given contest.

> Ballot #: 1234
> Prez: GW Bush
> Cat Catcher: WRITE-IN
>
> The voter can print out a ballot from a previous voter, even one that
> contains a vote for GW Bush (and maybe even a cat catcher write-in).
> But when the voter shows purported ballot #1234 to the Coercers, the
> Coercers will check the election website at the end of the day, and
> discover that ballot #1234 had a write-in of "Baz17" instead. Hence
> the non-compliance of the voter with Coercers is exposed.
>
Yes, write-ins present a problem for this scheme. Fortunately, write-ins
are almost never a factor.

> I would ask that Alan add this suggestion to the Security Wiki, and we
> discuss this there--including any annotations of attacks we notice (and
> responses to them, if applicable).
>
Okay.

Alan D.
==================================================================
= 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:10 2003

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