- is not a real time control problem
(at any rate, it is not a Hard Real Time problem)
- has very few inputs
- has very few outputs
- enjoys very simple reasonableness tests on its input data.

It beats me why the infamous US voting solutions apparently run to hundreds of thousands of lines of new code.

I also fear that the benefits of e-voting have been under-stated, which may trivialise the pursuit of a solution. More than merely saving cost to the government and delivering quicker results, e-voting …

- is more accessible for absentee voting
- possibly more inclusive
- has the massive scalability required for citizen initiated referenda and deliberative polling.

First I need to be sure that anyone reading this is aware that we’re talking about independent verification. You, someone not associated with the election authority, can write/use the software tool of your choosing to verify the correctness of a cryptographic identity used to prove the election tally.

“As far as I am aware there is no software out there that checks it’s own specification for correctness”

Agreed. But that’s not what we’re doing.

Think about an AES-128 implementation. It doesn’t check itself for correctness. You do. And it’s easy… a dozen test vectors and you’re done.

“If you have a specification with faults in it…”

We’re not talking about software specs. We’re talking about algorithmic (esp. cryptographic) specs.

1+1=2… that’s the spec by definition. There’s no room for philosophical argument. It is what it is, by definition. AES-128 has a specification too. And given its cryptographic nature, you can PROVE correctness of implementation with a dozen test vectors.

So if you write software that gives you 1+1=3, then you know you botched your implementation; it doesn’t matter what platform you use. 8088 or Core2… it doesn’t matter.

In this E2E (e.g. Punchscan) voting system audit business, that’s the bulk of what you’re doing: checking that something encrypted the way it was supposed to.

So it’s trivial get assurance of correctness of implementation, regardless of the platform. You can establish the cryptographic correctness with a dozen test vectors.

Once you have done so, you can audit the election with the assurance that you will catch any incorrect encryptions or tampering perpetrated by the election authority.

AND you can do it using any UTM you choose. 8086 or otherwise.

Think about the whole design process and the resulting product.

At one end you have the specification at the other the hardware, in between you have the software.

As far as I am aware there is no software out there that checks it’s own specification for correctness (it is infact probably impossible for it to do so), and there are very very few devices where the software can 100% test the hardware.

If you have a specification with faults in it, then the software that perfores the vote count, and the software that audits the count irespective of programing language or entities writting it are both likly to process the fault according to the specification (except by chance).

Likewise hardware changes without changes to the software, think for instance DOS Software written in the 1980s for the 8086 that still runs on the latest intel CPUs.

I think you will agree that if the software tested certain aspects of the 8086 operation then there is due to backwards compatability some expectation the modern CPU will respond in the correct way.

But the software will have no knowledge or ability to test the more modern features of the CPU that might well affect the outcome of the hardware usage.

The software is just one small part of the overal system, and it is all the individual parts of the system that have to work correctly 100% of the time ask yourself how likley this is to happen on the tenth let alone the first revision of the system…

1) The software is open source — you don’t trust the report, step through the program with a debugger and watch it perform the operations.

2) The software is open spec — you don’t like the implementation, write your own. If you can parse XML, and call a Crypto library, then you can do it with the language of your choice.

At the end of the day you’re saying a program that checks 1+1=2 can’t be trusted. But 1+1 is an open spec just like AES-128 and SHA-256. Plus you can buy any calculator you wish to perform it (or just do it by hand). Checking that something matches its commitment is just like checking an addition.

Regarding Punchscan, it is true that the audit will help catch certain errors, but the accuracy still depends on the software engineering of the application. The output I saw displayed by the auditor was a dialog box, saying that all selected votes had been successfully audited. If a bug in the program caused it to erroneously report that all is well, a problem would be missed.

Essentially this is a variation of N-version programming. One application generates the ballots and a different one checks them. Provided software errors are independent this should hugely reduce the error rate. The fact that they’re written in different languages will help too (was this intentional?)

Unfortunately Knight and Leveson showed that software errors are not independent, so it is fairly likely that the same flaw will exist in both the generator and auditor. There might even be code-sharing between the two applications, further increasing the chance of missing problems.

So auditing helps, but not quite as much as it might intuitively seem. It should be a component of a robust process (and it needs to be there for other reasons too), but is not a panacea and needs to be implemented as part of an integrated development process.

My only difference is that I am more optimistic regarding crypto voting. SSL is a black-box to the majority of internet shoppers or online bank customers who are content to “trust the cryptographers.”

I can also say that Punchscan takes reasonable measures to prevent having an election rerun as a result of errors or tampering. It includes audits before the election to ensure the parameters needed to conduct the election are correct, and after the election, a brand new tallying function can be created and used without having to reconduct the entire election.

That said, I am perfectly content with my country’s system (Canada) of hand-counting the ballots.

Even though paper balots are a well known quantity they like most other systems have scale issues, which is one of the reasons they will need to be replaced at some point in the not to distant future.

Another reason is that currently we do not have a democracy in the true sense but a Parlimentry Democracy, that is you vote for a person not on issues.

A lot of people feel that our current Parlimentary Democracy is full of crooks shysters and other undesirables, which might be one of the reasons voter turn out is about as low as it has ever got in this country.

If we are to move towards a more Democratic system we would effectivly need more occasions on which people vote on issues (ie a referendum). This would require not just trust worthy voting machines but a whole new rethink on how we carry a vote out.

Paper has been good for several hundred years but it needs to be updated to the needs of the modern world. If we do not get experiance on implementing voting machines or E-Voting then we will not be able to move forward.

It took the Germans many many trial flights to get the V2 to launch and travel in a predictable fashion. Likewise I can see many many attempts being made to get electronic voting working.

The scale issue, which you touch upon, is an important one which often resonates with politicians. Logistically it is much harder to change a significant number of paper ballots than electronic ballots. This has to be a good feature of paper elections that we remember and retain.

Secondly, not only does understanding the crypto require maths - as you point out, but even when open sourced, the e-voting or e-counting systems as a whole remain a black box to most people. Unless you have the skills, the time and are willing to do the work most voters will not examine the source code before voting on a system. Still even if we did view the source, how can we be sure that source is actually running on the system or that a flaw isn’t in the hardware?

There are too many opportunities to raise doubts over electronic elections to make them suitable for public use.

Plenty of aerospace projects don’t burn when they crash, for example the control software for sensors on probes. They are still developed using high-integrity software engineering techniques because if they fail you’ve sent an expensive brick across the solar system for nothing.

A failure of a voting machine is also extremely expensive. It’s not just the staff who have to come out and operate the polling stations, but voters have to waste time voting a second time. If you factor in the economic cost of that, you will end up with a very large number.

Also remember, electronic voting is supposed to make things better, not worse. I can’t think of a paper election which has had to be re-run due to failures, but if the keys are lost in a cryptographic scheme, you need to re-do it from scratch.

We could get by with voting machines that sometimes fail, provided they can be trusted to report all errors. Then a human can correct the problem, for example by a manual count.

Or for example cars. You don’t need a wonder vehicle which never runs out of petrol, it’s enough to that it has a fuel guage.