[Fwd: Re: [E-voting] About Estonian e-voting]
caburt at alphalink.com.au
Tue Oct 25 06:31:16 IST 2005
>> 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?
The voters and officials have to trust the auditors. The votes can be
decrypted by anyone who has the private key for the election and who
knows the very long password for it. The password is protected by
having itself been encrypted with passwords made up by all observers at
the time the election software is in draft.
So several officials must provide their passwords to decrypt the votes.
The votes can then be counted on screen, in a spreadsheet or they can be
exported and given to any third parties charged to count the votes. At
decrypt time we also check a forward hash of voter credentials that
travels with the vote is from the pool of credentials we issued in the
election. Whether these line up with identifying voter records or
whether they were shuffled and issued by another auditor depends on
whether the election is running in the UK or elsewhere.
>> 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.
The website has its own certificate and in fact, it doesn't matter where
the applet comes from, it matters where the vote goes and that the
voters can arbitrarily check the code signature on the applet. This bit
does have to work.
> But signing the code proves *nothing* to the voters, because they
> don't have a clue how the system is constructed.
No, they may not. But it is the sort of test you can describe in a few
sentences in electoral information that, if the test fails (and this is
reported quite clearly) has enormous ramifications for the integrity of
the election. That a selection of random voters will do this underpins
our confidence in the code not being manipulated in transit by a rogue
ISP or similar.
> 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)
Real voters can't confirm their votes made it either. They have to trust
(the postal service and) electoral people. There is necessary
suspension of doubt, but unlike paper voting, votes are protected from
tampering and substitution by any number of intervening people or
services between the voter and the ERO. Auditors play a role : perhaps
several if needed. So whereas in Ireland you rely on two police to
escort votes, online there are several auditors who sign the code and
several officials who control the creation and use of keys and voter
>>> 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
>>> 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.
I use as a model the Dutch KOA system which was used formal methods. It
would be ideal if there was a way to use this approach to examine the
applet code. There are automated tools that can certainly do some of
this work, but I expect you might prefer manual inspection.
More information about the E-voting