Re: Vote verification --- a futile exercise?
>>"Anthony" == Anthony DeRobertis <asd@suespammers.org> writes:
Hi,
Allow me to say, sir, that this post is mostly a load of
misconceptions, and attempting to apply a incompletely understood
principle to an incompletely understood process.
Anthony> 1) No voter can vote twice
You may, but latter votes override previous ones. Every person
gets one vote. The list of user ids published at the end must match
the final published tally sheet.
Anthony> 2) No voter can vote for another person
Yup. (The other person may challenge the vote, and ask for the
original signed message to be presented)
Anthony> 3) No voter can be denied his vote
Yes, cause they can then raise a stink about it. Not very
strong, perhaps, but in a community like ours, it would probably be
enough to guarantee close scrutiny, and perhaps a recount.
Anthony> 4) No person not registered to vote may vote.
All uids in the list of people voted must be in debian ldap
with a key fingerprint present in the debian keyring.
Anthony> 5) Each voter can verify the correctness of his vote
Sure can.
Anthony> 6) Every voter can verify the correct counting of the
Anthony> votes
If every voter verifies the correctness of their own vote,
everyone else can verify the counting, since a tally sheet is
published at the end.
Anthony> 7) No one can determine how another person voted
Yup. The list of voters and the tally sheets are not correlated.
Anthony> 8) No voter can prove to another person how he voted.
Umm. I don't see why this is a good thing. You can too prove
to another person how you voted, if you wish.
Anthony> 9) Everyone can prove the rules were followed.
Yup. You get the tally sheet, you verify the winner on your won.
Anthony> All the shared keys schemes proposed so far have failed to
Anthony> follow 5 and 9, and perhaps others.
That happens not to be the case.
Anthony> The reason is that nothing stops the secretary from adding
Anthony> additional votes.
There are things. There shall be a list of voters published at
the end, and people who did not vote, if their names are present, can
scream about it. If challenged, the secretary has to produce the
original signed message, and that can't be spoofed. Also, ex=chelon
can be consulted to determine if the people named on the list
actually sent in mail
Secondly, echelon records can be examined to show if a person
actually sent mail to the vote address.
Anthony> No one but the secretary knows the true number of votes received. No
Anthony> one can prove that number. Should the secretary wish to cheat, all he
Anthony> need to do is:
Anthony> 1) Generate whatever shared secret, hash, etc. proposed so far
With what user id?
Anthony> 2) Generate a vote to go with it
Anthony> 3) Tabulate that vote along with the legitimate ones
Anthony> 4) Add that shared secret to the list of votes
Anthony> 5) Lie about the number of votes received.
And what about the list of voters? I can't just add a vote,of voters.
I'll have to have a name to add to the published list of voters. How
do I fake echelon records? How do I prevent the voter from raising a
stink?
Anthony> You might think that (4) would be detected when the list was
Anthony> released, but it won't because there is no one to _deny_
Anthony> that vote.
Excuse me? What exactly does that mean? When you see a list of
people who have voted, complete with debian uid and name, you can
verify that uid has a key in the keyring. Names can't be made out of
whole cloth.
Anthony> You might think that (5) would be detected, but
Anthony> it won't because that would require every debian developer
Anthony> --- all 900 of them --- the prove they either did or did not
Anthony> vote. They can do no such thing, even if we could get them
Anthony> all to respond.
They can ask the secretary to prove they voted. And, if they
got an ack, they can display the token sent to them. So the secretary
can attempt to throw out a valid ballot -- but cannot make up
ballots. And, if they have voted, they have gotten an ack, and that
ack, along with the token they got, must match the list of fional
votes+md5sums. So they can, too, prove that they voted, and their
vote was on the final tally sheet.
If there are people whose vote is not present, and they
present the mail sent (with proper timestamps in the sig), hey, the
developers may ask for a recount.
All this is predicated on the developers being vigilant and
verifying their votes, and the secretary not knowing a priori who is
going to be lazy.
Anthony> The easiest solution is to make sure we can trust our vote
Anthony> counter. For other solutions, I will have to pull out
Anthony> Applied Crypto.
You should try understanding it too, sometime. This is not a
general election.
manoj
--
It's no use crying over spilt milk -- it only makes it salty for the
cat.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-vote-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: