[EM] 3ballot - revolutionary new protocol for secure secret ballot elections

[Juho]

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).

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.

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


	
	
		
___________________________________________________________ 
Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com