Clarification Request: Audit Device

[foundingnimo]

Pages 29-30, the sequence described in step (e) where the voting device re-encrypts the ballot can be read as though a different payload may be cast to the blockchain, and regardless of whether this is the same content as the original vote or not, it would read as though the hash might change and hence the auditing device may not be able to verify the amended transaction. I think some clarification would be good there.

Also, with third party auditors, would there be a possibility of authentication providers creating audit software, thereby having both the pseudonym and votes unencrypted?

[phayes]

You are correct that a compromised voting device may encrypt an incorrect vote and put it on the chain at this point. If it is audited a second time it will be caught, but if it is not audited again it will succeed in its ruse. For this reason it’s important that the voting device not know when it will be audited, making each time it cheats a risky affair.

It’s important to note that the Benaloh Challenge provides probabilistic protection against malicious voting devices, not an absolute one.

You are correct that the audit device has access to the unencrypted vote, and a malicious audit device may expose that vote. It is for this reason that we allow the voter to change their vote after the audit, allowing the voter to audit a “fake” vote if they so choose.

[foundingnimo]

Won't it still be vulnerable to voter coercion?

[phayes]

Hi @duckranger,

Can you expand on your question "Won't it still be vulnerable to voter coercion?". Is there a specific circumstance you're thinking of that we should address?

[foundingnimo]

If you can prove how you voted - won't it make the vote itself susceptible to manipulation (eg - I will pay you to vote X, and you can prove to me that you did..)

[phayes]

I think I see what you're suggesting (forgive me if I've misunderstood you). You're suggesting that an auditing device may act as a coercer (if that auditing device is controlled by some coercive agent)?

That shouldn't be possible. Let me walk through some of the steps of the Benaloh challenge to show why that is the case.

1. Voter finishes marking their ballot on the Voting Device.
2. The Voting Device encrypts the vote and displays a hash of the encrypted vote (as QR Code). This is the pre-commitment by the Voting Device to the encrypted ciphertext.
3. Voter opts to challenge the Voting Device using an Audit Device. Voter scans QR Code using audit-device to start this process. At this stage, the Voting Device does not know it's being audited. It is only after the voter inputs the audit-code into the Marking Device that the Marking Device knows it's being audited and will transmit the plaintext-vote and the randomization-factors the Audit Device.
4. Voter reviews the Audit Device and confirms that the Voting Device is honest (at least this time). Voter ends the audit process.
5. Marking Device re-encrypts the plaintext vote with new randomization factors. This is the critical part where the Voting Device breaks all bonds with the Audit Device, and protects the privacy of the vote from the Audit Device.
   6. The Marking Device presents the voter the the options to: Audit Again, Cast-the-Vote, Change-the-vote (remark their ballot).
6. The voter opts to "cast-the-vote" putting the encrypted vote onto the blockchain. The important thing here is that the audit device does not know if this cast-vote is the same one that was audited (merely with new randomization-factors), or if the voter opted to change their vote and remark their ballot, and it's an entirely new ballot.

Because the randomization factors are kept private to the Voting Device (and away from the audit device in a non-audit situation), the voter cannot prove to a coercer how they voted.

I hope I've shown that an Audit Device does not open a voter to coercion. The Voting Device however, if controlled by a coercive agent, is a different kettle of fish.

Because the Voting Device holds both the randomization-factors and the plaintext vote, may open the voter to coercion if controlled by a coercive agent. This can be considered a variant of Over-The-Shoulder Coercion, which our protocol does not explicitly address.

One way to stop device-oriented over-the-shoulder-coercion is to have the device not know who the voter is. This touches on the authn / authz portions of the protocol. Authn, Authz, and voting are all loosely coupled in our protocol to allow for implementations where the voting device does not know who the voter is. In this set-up, collusion between both an auth provider and a voting-device would be needed to coerce the voter. We recognize that this wouldn't be the common case where a voter is voting on their own personal mobile device, (where auth and voting all occur on the same device.)

[nateous]

I would think that it is no different than just telling someone how you voted. The only thing this adds is a way to verify that what they told you is actually how they voted. So, yes, once you allow someone to audit your vote, they would know how you voted. The ability to verify the vote wasn't rigged though is worth this potential. Again, you would only be open to this if you gave someone your "lookup" so that a third party could verify the vote correct? If you never gave it out to be audited you would be anonymous.

The only way to verify that your vote is correct and hasn't been tampered with, is to also allow you to give someone that same verified vote info. You just need to trust your vote auditor.