User: Password:
|
|
Subscribe / Log in / New account

Security quotes of the week

Security quotes of the week

Posted Feb 7, 2013 22:39 UTC (Thu) by renox (subscriber, #23785)
In reply to: Security quotes of the week by apoelstra
Parent article: Security quotes of the week

>> I have no doubt that internet voting could be made to work.
> Technologically, sure.

Who cares about the technology?
Internet voting allow effective purchase of votes and removes privacy (one family member could check what the other one is doing).


(Log in to post comments)

Security quotes of the week

Posted Feb 7, 2013 23:02 UTC (Thu) by apoelstra (subscriber, #75205) [Link]

> Internet voting allow effective purchase of votes and removes privacy (one family member could check what the other one is doing).

Well, you could still use (or even require) public kiosks, and keep using paper ballots in case a human recount is demanded. You'd still get improved count efficiency and consistent audit trails.

Alternately, you could allow multiple votes and only count the most recent one, which is easy to do if everybody has a unique encryption key.

This would handle problems of physical coercion. I don't see how buying votes would become any easier or harder.

Security quotes of the week

Posted Feb 7, 2013 23:28 UTC (Thu) by renox (subscriber, #23785) [Link]

>> Internet voting allow effective purchase of votes and removes privacy (one family member could check what the other one is doing).
> Well, you could still use (or even require) public kiosks

Then this is not anymore Internet voting, Internet voting is voting with your own PC..

Security quotes of the week

Posted Feb 14, 2013 4:27 UTC (Thu) by davidescott (guest, #58580) [Link]

> Alternately, you could allow multiple votes and only count the most recent one, which is easy to do if everybody has a unique encryption key.

"most recent" what does that mean? You've just moved a problem in security into one of atomicity and global timekeeping. I think Einstein would have some thoughts on how plausible this approach would be.

Security quotes of the week

Posted Feb 14, 2013 5:48 UTC (Thu) by apoelstra (subscriber, #75205) [Link]

>"most recent" what does that mean?

Time ordering would be determined by hash chains, probably. So you could see "vote X overrides vote Y" and there would be no way to interpret this as "vote Y overrides vote X".

No need to map to/from physical time, except by accident. So Einstein would be happy. :)

Security quotes of the week

Posted Feb 14, 2013 16:30 UTC (Thu) by davidescott (guest, #58580) [Link]

> Time ordering would be determined by hash chains, probably.

The obvious question is "hash chains of what?" I think you are pretty aware of one major challenge which is simplicity in that you earlier said:

> The simplicity thing is probably what will get you. Otherwise you could say "register a GPG key when you register to vote, then sign "I, ZZZ, vote for XXX at time YYY" and encrypt the signed message with the government voting key".

So lets replace "time YYY" with "most recent publicized hash base." It needs to be something public otherwise Fox News would have a field day. Pay a bunch of people to vote for Obama and submit that, and then wait until after the results are announced to produce a few thousand new votes properly signed with the government public key, and chained against the individuals previous vote in the register that are for Romney. THE ELECTION WAS RIGGED!!!! VOTERS CHANGING TO ROMNEY DENIED THE OPPORTUNITY!!!!!

So the government manages a clock/checkpoint which takes in all votes V_i arriving at time T, computes and publicizes a hash H_{T+1}=H(H_{T},V_1,...,V_n), and each vote includes as part of its signature H_{t} for some publicized t. If the vote has a stale Hash as the base to its signature I should reject it and notify the voter to resubmit.

There is still a synchronization point, but at least people will know about a failed vote and can resubmit. The problem here is that its split one vote counting problem into a few thousand vote counting problems. Every Joe who submits his vote at 11:59pm and sees it rejected is going to think he was targeted in his vote denial and not that his web connection was a bit slow.

There is also no simple way to verify that H_T was properly computed from the incoming votes and previous hash values. Independent observers will see votes arrive in a different order than the official hashing agent, and will compute different hashes as a result. Trying to reconcile that is going to be a mess and cause people to lose confidence in the system. My Server saw Joe's vote arrive at 11:01pm, but your server claimed it didn't arrive until 12:15am. Clearly you have a bug in your server's queue so I question every vote you tally or refuse to tally beginning at 11pm.

Security quotes of the week

Posted Feb 14, 2013 16:40 UTC (Thu) by davidescott (guest, #58580) [Link]

I'll back up a bit and challenge a more fundamental assumption:
> You'd still get improved count efficiency and consistent audit trails.

Count efficiency. Who says that is a problem? The vote is in November the but politicians don't begin serving until January. That leaves plenty of time to count and recount and recount again, and yet again. The only times that the outcome has been in doubt is when there is some disagreement about what constitutes a proper vote or a proper voter. ie hanging chads or provisional ballots. There are still "hanging chads" with electronic voting where the touchscreen gets miscalibrated or the machine crashes, and provisional ballots are entirely unaffected by electronic systems.

A judge isn't going to care that he can order up a spreadsheet that lists the winner and loser under a bunch of different potential rulings (ie we count the votes from Machine 23875 that failed in district 12, but not from machine 12123 in district 8 that was miscalibrated). In many ways the plausible existence of such a spreadsheet makes things worse for the judge. Its much easier to defend a ruling that says "count the hanging chads as yes" when you don't know for sure what the outcome will be.

Consistent Audit Trails. What makes a bunch of computer records a substantially better audit trail than a big heavy stack of papers in boxes that have to be physically moved around and physically manipulated to introduce fraud. In what way do we currently fail to have a consistent audit trail?


Copyright © 2018, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds