[Fwd: Re: [E-voting] About Estonian e-voting]

Michael McMahon michael at hexmedia.com
Mon Oct 24 16:37:15 IST 2005


Craig Burton wrote:

>
>>> The point of the mobile code, the signing etc is to make it so that 
>>> the server code cannot affect votes.  If it can't affect votes, then 
>>> it need not be trusted as much. The same is true for the data centre 
>>> operators, sysadmins etc.
>>>
>>
>> This doesn't make sense. If there are two components in a system
>> say A and B. A is audited and the code is signed by someone. B is 
>> not. A does some processing
>> and passes the data to B. B can do whatever it wants with the data.
>> The fact that A was signed doesn't help at all.
>
>
> If A is signed, it does what it is meant to do, it is difficult to 
> modify.  One of those things is to correctly encrypt our data.  It is 
> far better to protect data than it is to protect machines.  The 
> encrypted data are impossible to read.  We then sign the encrypted 
> data so they too are difficult to modify.  Then the data can then pass 
> through points B,C,D,E,F safely.  The remaining risks are that the 
> encrypted votes are either copied or deleted.  Copies are easy to 
> detect as they are identical and can be ignored.  Deleted votes are 
> harder to detect as we need our sample of voters to use the VVAT 
> system to detect a vote has gone missing.  This assumes all other 
> processes for preventing deletion have failed.
>
How does the voter know that the vote was encrypted if they have no way 
of verifying that fact, at each election?
Even if they trust someone who audited the code, and signed it, what 
happens at the point where the
vote is decrypted? What proof is there, that the counting system is not 
changing peoples votes?

> Perhaps I haven't explained this very well.  A massive piece of 
> software certainly is opaque.  What the above does it abstract out the 
> parts that are required to make or modify data (the votes).   If these 
> processes can be protected, and the votes they create can be 
> protected, than the 99% of the remaining software can do naught.
>
You are missing the point. What you are describing is a way for the 
developers of the system to
prove to *themselves* that the system is not corrupted. It makes sense 
to sign the downloadable code because
of the risk that a voter might be mistakenly directed to the wrong web 
site or whatever.
But signing the code proves *nothing* to the voters, because they don't 
have a clue how the system is constructed.
They don't know what the system is doing with their votes because there 
is no way to verify them.
The voters have to trust the developers (and anyone else who might be in 
a position to touch the system)

>
>> Unfortunately, code reviews just don't catch very many bugs. Most bugs
>> are found in testing and actual live use of a system. And if people 
>> cannot
>> verify their votes then there is no way of detecting them.
>
>
> It's not really a code review.  Ideally, the process should be like 
> program proving.
>
Program proving? You originally said it involved "inspection" which 
sounds like a code
review to me. Program proving is even less practical than inspection. 
Computational proofs
are more complicated than the software they are trying to prove. If you 
have discovered
a practical way of doing it, then you shouldn't be wasting time on this 
mailing list.

regards,
Michael



More information about the E-voting mailing list