[EM] An urgent plea for your assistance -- this is NOT spam!]
davek at clarityconnect.com
Mon Dec 15 21:21:01 PST 2003
On Mon, 15 Dec 2003 22:35:38 +0100 David GLAUDE wrote:
> Does anybody here believe a vendor will make any effort to write clean,
> standard, bug free, documented code if there is no reward for it, no
> penalty for ugly non-verifiable code and only insider will have a look
> at it?
Any PROPER contract has rewards for quality and penalties for failure.
"non-verifiable" reads as cause for rejection, though such a phrase may be
hard to define.
"only insiders" is not acceptable - agreed the general public is neither
able nor willing. Some validation should get done by contract, but anyone
willing should be permitted to inspect to their heart's content.
> Open Source, not Free Software (prefered) is the solution:
> 1) Only expert can read the code... 99.9% of the population must trust
> the other.
Given a million population, that gives me 1,000 experts. Only need
a few of them working at it.
The state, knowing of the experts, should test, rather than risking
getting caught not taking this step.
The vendors should not want to risk getting caught - and the
contract should provide punishment:
A little bit for the expectable unintentional errors.
REAL punishment for deliberate false content.
As to debating validity of a particular set of tools, I am not prepared,
nor is this amount of detail important this early. Some words about
quality can be useful.
Apparently "Open Source" identifies particular tools - I said "open
source" to identify a way of proceeding without identifying particular tools.
> 2) Durring the election, there is no way to know what software do run in
> the computer.
I do not have complete design, but my initial thoughts are:
A write-ONCE CD is prepared containing program and ballot definition
for this voting machine - leaving lots of empty space.
Load machine ready to open polls, including something unique,
perhaps partly contributed by poll watchers, such that content of this
machine could not have been predicted ahead of time.
Official invokes "Open Polls". This locks machine
against interference with its task. It records current memory content on
the CD, after which polls are open for voting.
Votes get recorded on the CD at time polls close and perhaps during
the election if volume requires this. They are recorded in blocks which
are constructed in memory with the votes in random order to preserve secrecy.
Official invokes "Close Polls". Machine records memory on the CD,
after which it unlocks.
Multiple copies of the CD should be made RIGHT NOW, such that those
who wonder what was in the machine can look for themselves.
> We have the code of Belgian e-voting system and we are unhappy with it:
> Casual inspection off the code reveals obvious errors (3),(5) from which
> we deduce scant peer review of the code, if any, has taken place. Nor do
> we see evidence that somebody has tackled the problem of creating
> entropy for the encryption keys (2). Also troubling is the fact that
> keeping the voting anonymous isn't high on the priorities list: global
> and stack variables are not zeroed after their useful lifetime has
> expired (1).
> 1) You do NOT vote in secret.
> 2) Generating entropy is a detail left to the compiler, if at all.
> 3) Using variables outside their defined scope.
> 4) There's not enough space to write a 64-bit hash to the card, so only
> 24 bits get written.
> 5) another OBVIOUS error that has escaped peer review:
> As computer scientist... the one I like best is
> void Generate_Mav_Session ()
> randomize(); // initializes random number generator
> for( int i=0; i < DESKEYLEN; i++)
> mavSessionKey [i] = random( 10) + '0'; // '0' to '9' is possible
> mavSessionKey [i] = 0;
From this distance I DO NOT KNOW what the language you are using might
say about this. If the compiler tolerates something the language forbids,
THEN it is time to complain.
Also time to complain about use of a language if THE LANGUAGE too
permissive as to dangerous coding practices.
randomize catches my eye. For MANY uses such a routine must produce a
predictable result, to make tests repeatable. For the randomizing of
order of votes that I write of above, the location of the initial vote in
the block must, itself, be random to preserve voter secrecy.
> A real compiler should not accept that...
> After the loop, "i" should be undefined.
> So saying "mavSessionKey [i] = 0;" should not compile and if it is
> compiled, then the behaviour is undefined and maybe unpredictable.
> Will it be DESKEYLEN-1? DESKEYLEN? or DESKEYLEN+1? or it depend on stack
> usage durring interrupt (IRQ).
> David GLAUDE
> Forest Simmons wrote:
>> On Mon, 15 Dec 2003, Dave Ketchum wrote:
>>> Further, if we frown on vendors copying each other - if we buy only
>>> open source then all can see whether there is any copying.
>> What computer scientist would be so stupid that he couldn't figure out how
>> to write a "For Loop" for adding up a bunch of numbers?
>> That's the first assignment in computer science 101.
Who, trying to solve the problem of constructing a voting machine, would
not realize that, while the task is simple compared to many computer
tasks, the above thought is not useful. Among the considerations:
There are many ways of voting, such a Plurality, Approval, IRV,
Write-ins must be attended to.
Must check whether voter has completed all of the voting intended.
Some voters need special services, such as being blind.
Getting from a list of offices to be voted on, to a ballot that is
convenient for the voter, without being especially demanding of the
election official needing to solve the problem, is a NONtrivial task.
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.
More information about the Election-Methods