You’re making a good point: how do we certify open-audit systems. I have one idea as to how to start: every open-audit system should publish a reference implementation of the verification program with detailed comments and explanations. That’s probably a great place to start the auditing process: what is the verification program verifying, and what guarantees does that verification give us? I’ll think about this some more and post thoughts in a few days. Thanks for bringing this up!

Hope you’re feeling better!

I think your proposal would certainly be better than what we currently have, but it would probably still be too onerous (and unjustifiably so given how much DRE+VVPAT gets a pass with very little real-world testing). I also think that, in the end, determining how to test crypto auditing will turn out to be a whole lot simpler than classic systems. But I digress a bit.

I would go further than you suggest and say that NIST and the TGDC should complete guidelines on testing cryptographic auditing, and the Holt bill could certainly point to that work as “the standard” for how these things should be tested. At least 2 crypto voting systems have been fully built and tested (VoteHere and Punchscan), which means this is a bit further along than a brand new innovation class.

That said, I think on the core we agree: having *something* in there that accounts for crypto voting and that doesn’t prescribe paper no matter what would be a good idea.

Ben, you suggest that the bill premise its requirements on “software independence” as articulated by NIST yet the STS subcommittee of the NIST TGDC has found it very difficult to write requirements and testing procedures for independent verification systems based purely on software. Their current proposal is to allow an “innovation class” where a party could propose a new voting system and NIST would come up with requirements and testing procedures for that new class of voting systems.

So, I think, if software-based IV were to be incorporated as an option in HR 811, the language should not be pinned on “software independence” but more along the lines of: “Any State wishing to use a technology that does not comply with the [paper record requirements] shall submit the technology as an innovation class to the NIST TGDC and have it federally certified in the innovation class to meet the auditability, durability, privacy-preserving and voter verification requirements of this Act.”

What do you think of this?

Ronald, you’re highly misinformed regarding crypto voting systems. I need to address your points in detail, lest they misinform others. I will do that in a follow-up blog post.

First, they are not proof against many presentation attacks (e.g., dropping candidates from the ballot, rearranging the ballot, modifying the headers between races, modulating the sensitivity of the touch-screen to make it more difficult to select certain candidates…) nor against delay- or denial-of-service attacks.

Second, though they might (or might not) be proof against vote-flipping attacks, they are not proof against vote-cancellation attacks. In such an attack, the attacker programs the machine to generate a corrupted electronic record of her vote, along with a matching cryptographic receipt. When the votes are tallied, the corrupt record will either not decrypt to anything sensible, or will decrypt, but will contain a bad signature (depending on the crypto scheme). Now it doesn’t matter whether the voter checks the tally, since both her electronic record and her receipt are corrupt.

Now let’s assume that the attacker corrupted enough records to theoretically flip the election. What do the officials do? Write it off as a “glitch” and certify the election, as is all too common with existing e-voting systems? Order a forensic investigation that concludes long after the fact, long after the attacker’s program has erased itself, and long after the election has been certified? Order a re-vote?

I don’t see that crypto voting solves much.

I’ll probably blog about this issue soon.