On Sun, 15 Oct 2006 20:56:21 +0300 Juho wrote:
> On Oct 15, 2006, at 20:06 , Dave Ketchum wrote:
>
>
>>On Sun, 15 Oct 2006 13:24:48 +0300 Juho wrote:
>>
>>>On Oct 15, 2006, at 7:02 , Dave Ketchum wrote:
>>>
>>>>Note that many voters will vote the same as for Plurality, for
>>>>which a special form might be possible.
>>>
>>>Yes, there is space for optimisation. Storing plurality style
>>>votes as they are should not be a big problem (for privacy in
>>>most cases). In situations where there are many candidates (e.g.
>>>100) voters probably typically name only few of their top
>>>preferences. Let's say that the voter votes A>B>C. One could
>>>first break this vote in three separate votes: A, B and C. But
>>>this is not exactly the same as the original vote, so one needs
>>>to fix the preferences between A, B and C. That would lead to
>>>additional [A>B], [A>C] and [B>C] ballots (where brackets mean
>>>that these ballots refer to only one pairwise comparison). This
>>>type of vote splitting saves a lot in the number of ballots if
>>>number of candidates is low and number of candidate entries is
>>>low in each vote. Privacy is still quite good. Voters will have
>>>it more difficult to check that their vote is recorded as
>>>intended (if they are supposed to check the paper ballots). Maybe
>>>sufficient number of voters are able to make the required checks
>>>to keep the probability of error/cheating detection high.
>>
>>Agreed, but clarifying that the additional fix vote messages are to
>>cancel what was overdone by the first three vote messages.
>
>
> With margins there is maybe be no need to cancel votes since (n+1)*
> ("A>B") + (n)*("B>A") has the same effect as one vote for "A>B". For
> winning votes one would need also cancellation. That would increase
> the number of ballots a bit and would make manual checking more
> complex (if one wants to have that - maybe you were happy to leave
> that out).
We are getting too deep, but my saying "cancel" above was to get to
EXACTLY the same destination as if the original votes had been counted.
>
> One additional observation on security.
> Rivest noted that if different voters generate different number of
> ballots, one should record and publish the number of ballots each
> voter generated. This might reveal something. Maybe ok, maybe to be
> patched e.g. by generation some random votes that cancel each others
> (to hide that I voted for three candidates "A>B>C").
>
>
>>>- open source and known platform also makes it possible to
>>>develop alternative code that could be somehow smuggled in to the
>>>voting machine (and the code could delete itself / return to the
>>>original code after the election)
>>
>>I have a different picture of open source:
>> It permits those who might do good by analyzing the source to
>>do so and admit doing it.
>> Those tempted to do evil can be expected to see the source
>>anyway.
>> Thus, either way, defenses are needed. Part of this would be
>>recording on the hard disk when anyone gains access (there could,
>>on rare occasions, be reasonable reasons for opening access to the
>>machine - but BETTER be able to and record the fact as a diary item).
>
>
> I'm most worried about malicious software that would be capable of
> making all the records look like nothing had happened and even the
> malicious code would be erased at the end. Open source is not
> essential here but it helps people developing such software. 1 minute
> access to the machine could be enough to install the malicious
> software. Did you maybe consider also cases where the voting machine
> would be physically protected so that all software would be in a ROM
> that can not be changed (ut could be read), or machines having two
> layers, one for making permanent records (with permanent code) of
> software updates and another layer with downloadable software (that
> would enable "recording access"). The latter trick would at least
> leave a trace of what has happened. The former trick would be safer
> but the machine would not be as flexible. Of course there would be
> still one more way, to make the device physically so safe that for
> software changes one would need to break locks etc.
I was thinking of the evil one being unable to erase anything from the
hard disk, including the record that recorded fact and time of opening.
The machine should be packaged such that gaining access for making trouble
would take MUCH more than a minute.
ROM is among the possible tools for protecting code. It is bo help for
protecting variables such as ballot content.
Anyway, our topic here should be that protection is needed and possible,
not to define how it shall be done.
>
> There are thus many options (that I tried to briefly sketch above)
> but I'm sure sufficient protection could be built for any particular
> need. Commercial (and whatever) products of today may not meet all
> the security requirements, and that may happen in the future too, but
> with the open process and open code things should get better.
>
> Juho Laatu
--
davek at clarityconnect.com people.clarityconnect.com/webpages3/davek
Dave Ketchum 108 Halstead Ave, Owego, NY 13827-1708 607-687-5026
Do to no one what you would not want done to you.
If you want peace, work for justice.