Re: open-audit elections

From: Ben Adida <ben_at_eecs_dot_harvard_dot_edu>
Date: Wed Dec 13 2006 - 13:15:23 CST

Hi all,

If anyone out there on the list is interested in really exploring
open-audit voting, then let me know, as right now the feedback is
entirely negative.


You're spreading significant false information to make your point. It
sounds like I'm getting fairly close to an answer to my question: you're
not interested in open-audit systems.

I'll try one more pass, in an effort to clear up some misconceptions.

> First, from a crakcing perspecting the encrytion is an input-output
> transformation that is invertable. For example: two applications of
> a public key encrytption like RSA is still a single mapping that
> inprinciple canbe inverted in one step.

Decrypting a banking transaction worth hundreds of millions of dollars
is technically "a single mapping that, in principle, can be inverted in
one step." Except that step would take longer than the age of the
universe to complete.

If the secrecy of your vote is worth more than a few hundred million
dollars, there are far easier ways to figure out how you voted, even if
you don't use crypto. Let's be realistic.

Also, it's important to point out that, even if somehow you did break
the cryptosystem, the *correctness* of the election would never be in
doubt. Privacy depends on not breaking the keys, but correctness is
guaranteed even if the keys are broken.

> second, in the end it has to be unencrypted to be used. It would seem
> that at that point the receipts can be tied to ballots if the data is
> leaked.

I was under the impression that you had investigated the VoteHere system
(and others like it), but it sounds like maybe you have not. I'll try to
explain briefly.

Encrypted votes are first shuffled through a process that strips
identity from encryptions, again in a publicly verifiable way that party
officials and other organizations can fully observe. You can think of
this as having each party official "shake the ballot box" while everyone
else is watching. The added bonus here is that "everyone else" means
really anyone with an Internet connection can watch.

Once votes are thus anonymized, then they are decrypted. So no, no
information leaks in the decryption process.

> third, at some point the mess has to be unencrypted and at that point
> you need all the keys. the whole thing is in unencrypted and if the
> data is grabbed at that moment then it appears you have a problem.

That is incorrect. Threshold decryption can be performed without "coming
together." Democrats perform their share of the decryption (from their
headquarters), and publish their results (which leak nothing, since it's
only partially decrypted). Then Republicans. Then Independents. And so
on and so forth. There is no single point of compromise.

Every such decryption is, once again, provided with a proof.

> fourth, from a practical perspective if every party is encoding the
> works with their own key then the every party also has the ability to
> accidentally lose their key and prevent the whole thing from working.
> One would have to invent some sort of elaborate redundant escrow
> process.

It's not all that elaborate, it's another application of secret sharing
so that it's possible to recover a lost key if enough other folks
certify that it indeed has been lost. Nothing fancy about this, it's
actually easy to implement.

> I fail to see how the key control problem has been solved.

These key control problems are *exactly* the same ones used in banking
applications, where these issues have been solved extremely well. It's
not that complicated.

>> Note that, after the election, it is expected that the secret
>> portion of the keys would be destroyed, leaving only the public
>> portions for verifiability. You only need *one* of the keys to be
>> appropriately destroyed to ensure that votes can no longer be
>> decrypted.
> That's not how votehere works. It requires decryption, so you can't
> discard the keys.

What I was trying to say is that you can discard the keys as soon as the
decryption (after the anonymization) has occurred, so that there's no
risk of later compromise. Officials only decrypting anonymized votes. If
a handful of officials want to decrypt un-anonymized votes, they'll fail
because they need all parties to collude.

VoteHere *definitely* implements threshold decryption, so that a single
key compromise does not violate voter privacy.

>> The key idea is that there is a short interaction between the
>> machine and the user that yields a confirmation code next to the
>> chosen candidate's name on the receipt.
> "Short" is hardly the word for it. Yes I have read the preposterous
> rigamrol the VoteHERE scheme requires to try to prove to the voter
> the receipt is not rigged. Having the voter verify that the two
> letter codes next to the candidates he chose match between the on
> screen version and the printed one. I assume you realize that will
> be nearly cognitively impossible in practice. As Selkirk has shown
> voters can barely verify a regular ballot. Moreover voters will not
> understand it.

Sure, let's talk about usability: there are other ways to do this and we
should have usability testing, and we should continually push the
envelope on this front.

That would be a productive discussion, but it's one that can only happen
if we agree that there's an interesting auditability property here that
we're trying to get.

Otherwise, we're wasting our time.

> It also does not seem to fix the misscan problem.

There's no scanning in VoteHere. The vote is recorded electronically and
it has to match you encrypted paper receipt.

>> There's some math in there that means the machine can't cheat, or
>> it will get caught by just running a simple verification program on
>> the receipt (that anyone can write.)
> If we wanted to leave it to verification programs to validate
> machines then why is it every single machine error known has happened
> on a system that passed all it's logic and accuracty test and
> software reviews.

Cryptographic verification is completely different from logic and
accuracy testing. Again, it's like verifying that 2+2=4. You can write
10 different programs, each written by someone with a different bias, to
check the answer, rather than verify a single program and hope you've
looked at every case.

Logic & Accuracy checks every path through a program, and that's why it
never really works (you can't check every path.) Crypto verification
checks only that a single output of the program is correct: the output
provided during elections. This works regardless of which path the data
went through inside the program.

I agree that Logic & Accuracy testing generally doesn't work. That's
*why* I'm in favor of end-to-end verification using cryptography.

> Yes but all this proves is that the encoded ballot was transmitted.
> Just as the poll book proves I voted. And the total ballots proves
> they all arrived. But in the vote here process the receipt codes are
> severed from ballots before they are counted.

This is false. There is no "severing." That's the entire point of
cryptography-based voting. Because the vote is encrypted, you don't need
to "sever" the auditing connection. You get mathematical proofs that the
actual posted votes are shuffled, decrypted, and counted.

It's interesting that you're so worried about "severing" here, where it
does not happen, but you're not worried about it in a chain-of-custody
election, where it happens at every step. There's severing between the
source code audit and its installation on the voting machine. There's
severing when the voting machines are transported to the polling
location. There's severing when ballot boxes are transported back to
headquarters. etc....

> At that point any
> different set of ballots could be substituted and no one could tell.
> the list of receipts does not prove my ballot was counted or counted
> as cast. All this does is move the point where cheating is easy from
> the distributed precincts where it's hard for one person to do a lot
> of damage, to the central count where one person could change then
> entire outcome. The same can be said for counting mistakes.

No, this is false.

> there is infact no open audit whatsoever since there is zero
> connection between the published receipts and the actual vote counts.

Again, completely false.

I'm happy to go into details, but it's important to point out that
you're now spreading factually incorrect information. If you don't
understand the VoteHere system, that's totally okay with me, I don't
expect that everyone will have read it. But at least don't spread
incorrect information. That hurts the debate significantly.

OVC-discuss mailing list
= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
Received on Sun Dec 31 23:17:12 2006

This archive was generated by hypermail 2.1.8 : Sun Dec 31 2006 - 23:17:16 CST