[This post was written by David Robinson and me, based on our discussions with Alex Halderman, Joe Calandrino, and Ari Feldman.]

On Tuesday, the Information Technology and Innovation Foundation released a report on the possible role of paper trails in auditing elections conducted using DRE machines. The report contained a blend of reasonable and unreasonable claims, and careful and uncareful argumentation. A lay reader might come away from the report – entitled Stop the Presses: How Paper Trails Fail to Secure e-Voting – with the belief that the addition of paper trails to DRE voting machines makes them less secure than they are on their own. Such a belief would be incorrect.

As the report puts it at one point, “The addition of paper audit trails to DRE voting machines would simply convert our elections back to a paper ballot system.” The report dwells at remarkable length on the convenient appearance of extra ballots during Lyndon Johnson’s political career. But we know about that cheating today precisely because paper ballots, unlike many DRE vote tallies, can be independently recounted.

One could spend months arguing about what exact position emerges from the 19 pages of delicately drafted hedging that make up the body of this report. But the bottom line – contrary to the impression most readers will gather from the report – is that paper and electronic voting together are, if done right, better than either the best paper system or the best computerized system would be alone.

The ITIF report suggests that a situation in which the paper and electronic records don’t match would be a disaster, since authorities wouldn’t know which record to trust. But that’s a shortsighted view. Divergent paper and electronic records are a sure sign that something has gone awry during voting. In some cases, that sign lets officials make a reasonable judgment about which record is, under the specific circumstances of a given race, more likely to be trustworthy.

The real worst-case scenario isn’t divergent paper and electronic records – with their attendant litigation and political discord. The real worst case is an attack or error that never even comes to the attention of election officials or the public, because there isn’t an independent way of catching problems.

Yesterday the California Secretary of State released the reports of three source code study teams that analyzed the source code of e-voting systems from Diebold, Hart InterCivic, and Sequoia.

• Diebold systems
• Hart InterCivic systems
• Sequoia systems

All three reports found many serious vulnerabilities. It seems likely that computer viruses could be constructed that could infect any of the three systems, spread between voting machines, and steal votes on the infected machines. All three systems use central tabulators (machines at election headquarters that accumulate ballots and report election results) that can be penetrated without great effort.

It’s hard to convey the magnitude of the problems in a short blog post. You really have read through the reports – the shortest one is 78 pages – to appreciate the sheer volume and diversity of severe vulnerabilities.

It is interesting (at least to me as a computer security guy) to see how often the three companies made similar mistakes. They misuse cryptography in the same ways: using fixed unchangeable keys, using ciphers in ECB mode, using a cyclic redundancy code for data integrity, and so on. Their central tabulators use poorly protected database software. Their code suffers from buffer overflows, integer overflow errors, and format string vulnerabilities. They store votes in a way that compromises the secret ballot.

Some of these are problems that the vendors claimed to have fixed years ago. For example, Diebold claimed (p. 11) in 2003 that its use of hard-coded passwords was “resolved in subsequent versions of the software”. Yet the current version still uses at least two hard-coded passwords – one is “diebold” (report, p. 46) and another is the eight-byte sequence 1,2,3,4,5,6,7,8 (report, p. 45).

Similarly, Diebold in 2003 ridiculed (p. 6) the idea that their software could suffer from buffer overflows: “Unlike a Web server or other Internet enabled applications, the code is not vulnerable to most ‘buffer overflow attacks’ to which the authors [Kohno et al.] refer. This form of attack is almost entirely inapplicable to our application. In the limited number of cases in which it would apply, we have taken the steps necessary to ensure correctness.” Yet the California source code study found several buffer overflow vulnerabilities in Diebold’s systems (e.g., issues 5.1.6, 5.2.3 (“multiple buffer overflows”), and 5.2.18 in the report).

As far as I can tell, major news outlets haven’t taken much notice of these reports. That in itself may be the most eloquent commentary on the state of e-voting: reports of huge security holes in e-voting systems are barely even newsworthy any more.

I wrote Monday about the California Secretary of State’s partial release of report from the state’s e-voting study. Four subteams submitted reports to the Secretary, but as yet only the “red team” and accessibility teams’ reports have been released. The other two sets of reports, from the source code review and documentation review teams, are still being withheld.

The Secretary even held a public hearing on Monday about the study, without having released all of the reports. This has led to a certain amount of confusion, as many press reports and editorials (e.g. the Mercury News editorial) about the study seem to assume that the full evaluation results have been reported. The vendors and some county election officials have encouraged this misimpression – some have even criticized the study for failing to consider issues that are almost certainly addressed in the missing reports.

With the Secretary having until Friday to decide whether to decertify any e-voting systems for the February 2008 primary election, the obvious question arises: Why is the Secretary withholding the other reports?

Here’s the official explanation, from the Secretary’s site:

The document review teams and source code review teams submitted their reports on schedule. Their reports will be posted as soon as the Secretary of State ensures the reports do not inadvertently disclose security-sensitive information.

This explanation is hard to credit. The study teams were already tasked to separate their reports into a public body and a private appendix, with sensitive exploit-oriented details put in the private appendix that would go only to the Secretary and the affected vendor. Surely the study teams are much better qualified to determine the security implications of releasing a particular detail than the lawyers in the Secretary’s office are.

More likely, the Secretary is worried about the political implications of releasing the reports. Given this, it seems likely that the withheld reports are even more damning than the ones released so far.

If the red team reports, which reported multiple vulnerabilities of the most serious kind, are the good news, how bad must the bad news be?

UPDATE (2:45 PM EDT, August 2): The source code review reports are now up on the Secretary of State’s site. They’re voluminous so I won’t be commenting on them immediately. I’ll post my reactions tomorrow.