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

[Dave Ketchum]

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.

I keep leaning on machines neither doing errors nor tolerating cheating.

All of this differs from Plurality, for which the voter could favor only 
one candidate, and that favoring was all that needed recording.
> 
>>I would DEMAND that the record being prepared for hard disk have  
>>the ballots in true random order (sometimes those needing a random  
>>sequence of numbers use a formula that would give the same results  
>>tomorrow as it did today),
>>     Thinking, without studying, could the space used for  
>>accumulating data for records for this hard disk be such that no  
>>data would be lost even with expectable power failures?
> 
> 
> I think all this is doable with open source but of course requires  
> more work than ordinary software development.
> 
> Some remaining threats/problems:
> - 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).

> - we may need solutions also for the case where only very few voters  
> have voted with the machine ad we therefore need to merge those votes  
> with some other lots of votes to guarantee privacy

When electing dogcatcher, privacy may be impossible - but this is not 
likely to be life shattering.

When electing governor, most of the votes will be in larger districts and, 
provided those are protected, what happens in a fringe district will not 
be so important - such a district cannot, by itself, pick a winner.  But, 
for the moment, I favor reporting the district counts - if the counts say 
all four voters voted for X and I, one of them, voted for Y, I can smell 
trouble.

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