'Electronic voting will never be 100% secure' - draft zero
In a future post I'll make the following points:
- electronic voting will never be 100% secure
- perhaps the old ways are best
- righties should take this issue away from the Loony Left
Here's draft zero of part of it:
The Johns Hopkins report raises several issues with a Diebold system, the software for which had appeared on the web. They discuss how that Diebold system comes with smart card readers, and all the hacking that that allows.
The solution, as I have pointed out a few times, is this:
- paper print out of some kind
- voter verifies his paper
- paper put in ballot box
- a percentage of paper ballots are counted (say, 10%)
- discrepancies between the paper sample count and the electronic results leads to all paper ballots being counted
- paper ballots are considered the real ballots in case they have to be countedThat rules out almost all of the attacks mentioned in the report.
As for the report itself, I have a few problems with it. Here are a few:
The authors state "Of course, a better solution would have been to write the entire system in a safe language, such as Java or Cyclone. In such a language we would be able to prove that large classes of attacks, including buffer overflows and type-confusion attacks, are impossible assuming a correct implementation of the compiler and runtime system."
I think - but I'm not sure - that with enough work I might be able to confuse Java's type system.
In any case, the phrase "assuming a correct implementation of the compiler and runtime system" is the killer. There are many, many bugs in Sun's Java implementations, and I'd imagine there are many in any other group's implementation as well. Malicious Java code could take advantage of those bugs to make the VM crash. I doubt there will exist a VM that will not crash under some set of circumstances. And, those VMs are written in "unsafe" (author's phrase) languages like C++.
The report says "Due to... the use of third-party code and operating systems we believe that any sort of comprehensive, top-to-bottom code review would be nearly impossible."
Yet, they also recommend it be written in Java. In almost all cases, Java is yet another layer of software that runs on top of an OS. That OS might be Windows, or it might be Linux, but Java still requires an OS.
Using this same argument, they could chase their tail down to the silicon atoms. Even if they used a Java processor and a small OS on specialized hardware, someone could insert hacking code into the CPU's microcode (or into the network card, etc.)
The authors also plump for Open Source and Linux. The fact that they appear to be advocates for those does not make me look at them in a good light. Not that those are bad things, but advocating for them over, for instance, MS products adds bias to their report.
It's good the authors took apart the Diebold system, but they should expend the same effort encouraging that only audit trail systems are used.