Re: Vote verification --- a futile exercise?
On Fri, 2002-04-05 at 04:51, Richard Braakman wrote: Oh... I just realized that per-day batching would still not work. Suppose the vote taker's favourite candidate does something really unpopular halfway through the vote (such as revealing his Secret Master Plan to Take Over the World). In that case, dropping votes from the second half of the voting period could affect the outcome. You'd have to be able to predict that the candidate would have such a plan, and would reveal it in the middle of the election. This might not be a problem if the CTF is also the Second-In-Command, Evil Plot, Inc. The general problem still remains, however: if the CTF can drop random unknown votes, and if the CTF can correlate any outside event with probabilities in voter activity times, then the CTF can exert influence on the election results. Even something like a popular tech conference (Euro voters are all at CeBIT this week) or a holiday (all the Irish developers are too busy partying to vote on St. Patrick's Day) could be used. Using this protocol, the best solution to all these problems is voter vigilance. If enough voters threw a fit that their votes weren't being published, then (as you pointed out), the whole election process could be stopped pending an investigation. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Vote verification --- a futile exercise?
On Fri, 2002-04-05 at 04:51, Richard Braakman wrote: Oh... I just realized that per-day batching would still not work. Suppose the vote taker's favourite candidate does something really unpopular halfway through the vote (such as revealing his Secret Master Plan to Take Over the World). In that case, dropping votes from the second half of the voting period could affect the outcome. You'd have to be able to predict that the candidate would have such a plan, and would reveal it in the middle of the election. This might not be a problem if the CTF is also the Second-In-Command, Evil Plot, Inc. The general problem still remains, however: if the CTF can drop random unknown votes, and if the CTF can correlate any outside event with probabilities in voter activity times, then the CTF can exert influence on the election results. Even something like a popular tech conference (Euro voters are all at CeBIT this week) or a holiday (all the Irish developers are too busy partying to vote on St. Patrick's Day) could be used. Using this protocol, the best solution to all these problems is voter vigilance. If enough voters threw a fit that their votes weren't being published, then (as you pointed out), the whole election process could be stopped pending an investigation. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Election status
On Thu, 2002-04-04 at 17:04, Peter Palfrader wrote: While we're at it, it would be pretty cool to have a voting protocol where no one, not even the secretary, can find out other peoples' votes. Is such a thing possible? Yes. See, for example, my followup to the vote verification thread. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Vote verification --- a futile exercise?
On Thu, 2002-04-04 at 17:53, Richard Braakman wrote: On Thu, Apr 04, 2002 at 12:11:32AM -0500, Jeff Licquia wrote: Also, the CTF may drop votes, and the voter cannot prove that (s)he actually voted properly; one would think, though, that if this happened enough to influence the election, enough of a public stink would be raised that the election results would be suspect. Hmm... the CTF can drop votes, but not after it has published the encrypted message containing the vote. And it doesn't get the decryption key for the vote until after all votes have been collected. So the CTF can drop votes, but it won't know whose votes they are or what the votes contain, so this is a suboptimal way of affecting the election results :) Not necessarily. Consider this election, for instance; since Raphael is the only European and only non-American candidate, this implies that he will have greater support in Europe and areas considered anti-American. If Manoj happened to want to influence the election against Raphael, he could plot out timezones and look at times when voters from those areas were more or less likely to vote (say, when local time is 5 am versus 7 pm) and randomly drop votes to coincide with times that pro-European/anti-American voters were most likely to vote and pro-American voters least likely. In a close race, this could affect the outcome. [Again, not that Manoj would ever do such a vile thing.] In addition, the voters involved can raise a stink _before_ the votes are counted, because they can refuse to send in their private keys until the matter is investigated. That's true; I hadn't considered that possibility. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Election status
On Thu, 2002-04-04 at 17:04, Peter Palfrader wrote: While we're at it, it would be pretty cool to have a voting protocol where no one, not even the secretary, can find out other peoples' votes. Is such a thing possible? Yes. See, for example, my followup to the vote verification thread. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Vote verification --- a futile exercise?
On Thu, 2002-04-04 at 17:53, Richard Braakman wrote: On Thu, Apr 04, 2002 at 12:11:32AM -0500, Jeff Licquia wrote: Also, the CTF may drop votes, and the voter cannot prove that (s)he actually voted properly; one would think, though, that if this happened enough to influence the election, enough of a public stink would be raised that the election results would be suspect. Hmm... the CTF can drop votes, but not after it has published the encrypted message containing the vote. And it doesn't get the decryption key for the vote until after all votes have been collected. So the CTF can drop votes, but it won't know whose votes they are or what the votes contain, so this is a suboptimal way of affecting the election results :) Not necessarily. Consider this election, for instance; since Raphael is the only European and only non-American candidate, this implies that he will have greater support in Europe and areas considered anti-American. If Manoj happened to want to influence the election against Raphael, he could plot out timezones and look at times when voters from those areas were more or less likely to vote (say, when local time is 5 am versus 7 pm) and randomly drop votes to coincide with times that pro-European/anti-American voters were most likely to vote and pro-American voters least likely. In a close race, this could affect the outcome. [Again, not that Manoj would ever do such a vile thing.] In addition, the voters involved can raise a stink _before_ the votes are counted, because they can refuse to send in their private keys until the matter is investigated. That's true; I hadn't considered that possibility. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Vote verification --- a futile exercise?
On Wed, 2002-04-03 at 14:33, John H. Robinson, IV wrote: On Wed, Apr 03, 2002 at 01:58:36PM -0500, Jeff Licquia wrote: (Whether it's practically possible is another matter; it's been a while since I've real _Applied Cryptography_.) i've never read it. perhaps i should put that on my to-read list. It's one of the classics of programming wisdom. I believe all programmers should read it, if only to absorb a little of Bruce Schneier's intellectual vigor. so how can we facilitate 5, while keeping 8 true? I'd have to look it up to be sure, and my copy is at home. The goal is to prove fact A to person B in such a way that the proof can't be replayed to person C. There actually is a cryptographic protocol that can pull this off. in a paper puch ballot, at least in my voting district, you get a little receipt with a number, that number matches the number on the ballot itself. the only way to prove how i voted is to match my little recepit with the paper ballot locked away somewhere (yes, for those interested, i ensured i had no hanging or swinging chads ;). of course, i could not prove to my own satisfaction that my vote was actually counted :( With a paper system, there's no ironclad way to verify these things; that's why we have election monitors, locked ballot boxes, and disputes. Digital voting solves some of those problems, but opens up others. If cryptographers can ever solve those new problems, digital voting will rock. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Vote verification --- a futile exercise?
On Wed, 2002-04-03 at 00:16, Anthony DeRobertis wrote: I assume the following are the goals of verifying a vote. I believe these goals are justified: All the fun discussion tweaked my curiosity, so I pulled Schneier down from the shelf and did some reading. The results are interesting. For posterity, here's a brief summary. This is from _Applied Cryptography_, 2nd edition, section 6.1. (In my printing, it starts on page 125.) NOTE: I am NOT criticizing the current voting protocol, or anyone's integrity or anything; this is an intellectual exercise. First off, Schneier has six requirements for a secure election, and one sometimes requirement. 1) No voter can vote twice This is number two. 4) No person not registered to vote may vote. This is number one. 6) Every voter can verify the correct counting of the votes This is number six, sort of. Schneier actually is only concerned with each voter being able to see that his/her vote was counted. 7) No one can determine how another person voted This is number three. [ I really should grab Applied Crypto and make sure I didn't miss any ] You missed two: 4. No one can duplicate anyone else's vote. 5. No one can change anyone else's vote without being discovered. And the optional requirement: 7. Everyone knows who voted and who didn't. Interestingly, Schneier considers number four to be the tough requirement. All the shared keys schemes proposed so far have failed to follow 5 and 9, and perhaps others. The reason is that nothing stops the secretary from adding additional votes. Your steps 5 and 9 aren't important; however, steps 5 and 6 are pretty much identical if you define the vote as the voter's intent, and step 9 is sort of assumed in all cryptographic protocols - that no one can break the rules without someone else knowing. Several protocols are discussed in the chapter. The first ones are flawed in some way. The last protocol discussed that assumes a central tabulator is claimed to meet all six of the real requirements and has two other nice features: 8. A voter can change his mind within a certain time frame. 9. Voters can correct misvotes without compromising the ballot's secrecy. The basic protocol goes something like this: All voters register their intent to vote, and the central tabulating facility (CTF) publishes the list of voters intending to vote. Each voter gets a unique ID number anonymously; the CTF has the list of IDs, but only the voter can associate himself with a particular ID. The voter generates a public/private key pair, combines the ID with his/her vote, encrypts that with the public key (s)he generated, and sends that anonymously to the CTF along with the plaintext ID. The CTF then publishes the encrypted message. Finally, all the voters send their private keys and IDs to the CTF (again, anonymously), who decrypts all the votes and publishes the results, along with all the encrypted messages. If the voter wants to change his/her vote or notices it is wrong, (s)he combines the vote with the ID, encrypts that, then sends the plaintext ID, the encrypted message, and the private key to the CTF, again anonymously. The trick is distributing unique IDs securely and anonymously. Two techniques are mentioned: blind signatures and all-or-nothing disclosure of secrets (ANDOS). Schneier goes into more detail with the ANDOS version. Blind signatures amount to a way of signing something without knowing what it is, but with confidence that it isn't something you don't want to sign. ANDOS is a way of distributing a set of secrets such that another person can learn one secret of his/her choice, but no others. Voters can't cheat with this. They can't use the same ID twice, or pick their own ID, because the plaintext ID is embedded in the encrypted message containing the vote, and the CTF knows all the valid IDs. They can't pretend to be someone else, because they'd need to guess a valid ID held by someone else. If the same ID comes in encrypted with two different private keys, the CTF picks one, generates a new unique ID, and publishes the new ID together with that original encrypted vote. That voter is then responsible for noticing the new ID and sending in a new vote, using the new ID from the CTF instead of the original one; otherwise, the vote is discarded. Thus, at most, one person could get multiple votes; if the IDs are random enough, this won't be a serious problem. This doesn't eliminate the problem of trusting the CTF, although it limits the CTF's options; the CTF may still proxy vote all non-voting IDs at the end of the election. Having voters declare their intention to vote mitigates this somewhat, since this reduces the number of unused IDs; if a voter declares his/her intention and then doesn't vote, however, that vote is the CTF's for the taking. Also, the CTF may drop votes, and the voter cannot prove that (s)he actually voted
Re: Vote verification --- a futile exercise?
On Wed, 2002-04-03 at 12:48, John H. Robinson, IV wrote: On Wed, Apr 03, 2002 at 12:16:18AM -0500, Anthony DeRobertis wrote: 5) Each voter can verify the correctness of his vote 8) No voter can prove to another person how he voted. these two seem mutually exclusive. if you can prove your own vote, how could you possibly not be able to prove that vote to another person? You don't have to prove to yourself that you voted for, say, Raphael; the only proof you need for your own vote is that it was tallied properly. OTOH, other people have no way of knowing for certain that you voted for Raphael without an external source of information. Goal 8 seeks to remove as many of those external sources as possible. It's theoretically possible to satisfy both goals at once. (Whether it's practically possible is another matter; it's been a while since I've real _Applied Cryptography_.) [Any resemblence to actual votes, real or imagined, is purely coincidental.] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Vote verification --- a futile exercise?
On Wed, 2002-04-03 at 14:33, John H. Robinson, IV wrote: On Wed, Apr 03, 2002 at 01:58:36PM -0500, Jeff Licquia wrote: (Whether it's practically possible is another matter; it's been a while since I've real _Applied Cryptography_.) i've never read it. perhaps i should put that on my to-read list. It's one of the classics of programming wisdom. I believe all programmers should read it, if only to absorb a little of Bruce Schneier's intellectual vigor. so how can we facilitate 5, while keeping 8 true? I'd have to look it up to be sure, and my copy is at home. The goal is to prove fact A to person B in such a way that the proof can't be replayed to person C. There actually is a cryptographic protocol that can pull this off. in a paper puch ballot, at least in my voting district, you get a little receipt with a number, that number matches the number on the ballot itself. the only way to prove how i voted is to match my little recepit with the paper ballot locked away somewhere (yes, for those interested, i ensured i had no hanging or swinging chads ;). of course, i could not prove to my own satisfaction that my vote was actually counted :( With a paper system, there's no ironclad way to verify these things; that's why we have election monitors, locked ballot boxes, and disputes. Digital voting solves some of those problems, but opens up others. If cryptographers can ever solve those new problems, digital voting will rock. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Vote verification --- a futile exercise?
On Wed, 2002-04-03 at 00:16, Anthony DeRobertis wrote: I assume the following are the goals of verifying a vote. I believe these goals are justified: All the fun discussion tweaked my curiosity, so I pulled Schneier down from the shelf and did some reading. The results are interesting. For posterity, here's a brief summary. This is from _Applied Cryptography_, 2nd edition, section 6.1. (In my printing, it starts on page 125.) NOTE: I am NOT criticizing the current voting protocol, or anyone's integrity or anything; this is an intellectual exercise. First off, Schneier has six requirements for a secure election, and one sometimes requirement. 1) No voter can vote twice This is number two. 4) No person not registered to vote may vote. This is number one. 6) Every voter can verify the correct counting of the votes This is number six, sort of. Schneier actually is only concerned with each voter being able to see that his/her vote was counted. 7) No one can determine how another person voted This is number three. [ I really should grab Applied Crypto and make sure I didn't miss any ] You missed two: 4. No one can duplicate anyone else's vote. 5. No one can change anyone else's vote without being discovered. And the optional requirement: 7. Everyone knows who voted and who didn't. Interestingly, Schneier considers number four to be the tough requirement. All the shared keys schemes proposed so far have failed to follow 5 and 9, and perhaps others. The reason is that nothing stops the secretary from adding additional votes. Your steps 5 and 9 aren't important; however, steps 5 and 6 are pretty much identical if you define the vote as the voter's intent, and step 9 is sort of assumed in all cryptographic protocols - that no one can break the rules without someone else knowing. Several protocols are discussed in the chapter. The first ones are flawed in some way. The last protocol discussed that assumes a central tabulator is claimed to meet all six of the real requirements and has two other nice features: 8. A voter can change his mind within a certain time frame. 9. Voters can correct misvotes without compromising the ballot's secrecy. The basic protocol goes something like this: All voters register their intent to vote, and the central tabulating facility (CTF) publishes the list of voters intending to vote. Each voter gets a unique ID number anonymously; the CTF has the list of IDs, but only the voter can associate himself with a particular ID. The voter generates a public/private key pair, combines the ID with his/her vote, encrypts that with the public key (s)he generated, and sends that anonymously to the CTF along with the plaintext ID. The CTF then publishes the encrypted message. Finally, all the voters send their private keys and IDs to the CTF (again, anonymously), who decrypts all the votes and publishes the results, along with all the encrypted messages. If the voter wants to change his/her vote or notices it is wrong, (s)he combines the vote with the ID, encrypts that, then sends the plaintext ID, the encrypted message, and the private key to the CTF, again anonymously. The trick is distributing unique IDs securely and anonymously. Two techniques are mentioned: blind signatures and all-or-nothing disclosure of secrets (ANDOS). Schneier goes into more detail with the ANDOS version. Blind signatures amount to a way of signing something without knowing what it is, but with confidence that it isn't something you don't want to sign. ANDOS is a way of distributing a set of secrets such that another person can learn one secret of his/her choice, but no others. Voters can't cheat with this. They can't use the same ID twice, or pick their own ID, because the plaintext ID is embedded in the encrypted message containing the vote, and the CTF knows all the valid IDs. They can't pretend to be someone else, because they'd need to guess a valid ID held by someone else. If the same ID comes in encrypted with two different private keys, the CTF picks one, generates a new unique ID, and publishes the new ID together with that original encrypted vote. That voter is then responsible for noticing the new ID and sending in a new vote, using the new ID from the CTF instead of the original one; otherwise, the vote is discarded. Thus, at most, one person could get multiple votes; if the IDs are random enough, this won't be a serious problem. This doesn't eliminate the problem of trusting the CTF, although it limits the CTF's options; the CTF may still proxy vote all non-voting IDs at the end of the election. Having voters declare their intention to vote mitigates this somewhat, since this reduces the number of unused IDs; if a voter declares his/her intention and then doesn't vote, however, that vote is the CTF's for the taking. Also, the CTF may drop votes, and the voter cannot prove that (s)he actually voted
[Fwd: Mail delivery failed: returning message to sender]
-Forwarded Message- From: Mail Delivery System [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Mail delivery failed: returning message to sender Date: 26 Mar 2002 23:01:45 -0600 This message was created automatically by mail delivery software. A message that you sent could not be delivered to one or more of its recipients. The following address(es) failed: [EMAIL PROTECTED]: generated |/org/vote.debian.org/bin/debvote-spool.pl -c /org/vote.debian.org/data/leader2002/debvote /org/vote.debian.org/data/leader2002/log/mailerror 21 The following text was generated during the delivery attempt: -- |/org/vote.debian.org/bin/debvote-spool.pl -c /org/vote.debian.org/data/leader2002/debvote /org/vote.debian.org/data/leader2002/log/mailerror 21 -- Can't open : No such file or directory Can't open /org/vote.debian.org/data/leader2002/log/mailerror: No such file or directory Can't open 21: No such file or directory -- This is a copy of the message, including all the headers. -- Return-path: [EMAIL PROTECTED] Received: from 12-222-16-44.client.insightbb.com (sentinel.licquia.org) [12.222.16.44] by master.debian.org with esmtp (Exim 3.12 1 (Debian)) id 16q5Z9-00031i-00; Tue, 26 Mar 2002 23:01:43 -0600 Received: from server1.internal.licquia.org (server1.internal.licquia.org [192.168.50.3]) by sentinel.licquia.org (Postfix) with ESMTP id D9CD245292 for [EMAIL PROTECTED]; Wed, 27 Mar 2002 00:01:38 -0500 (EST) Received: by server1.internal.licquia.org (Postfix, from userid 1000) id A737120F01B; Wed, 27 Mar 2002 00:01:38 -0500 (EST) Subject: Re: Call for votes for the debian project leader election 2002 From: Jeff Licquia [EMAIL PROTECTED] To: [EMAIL PROTECTED] In-Reply-To: [EMAIL PROTECTED] References: [EMAIL PROTECTED] Content-Type: multipart/signed; micalg=pgp-sha1; protocol=application/pgp-signature; boundary==-HiTjA4f5hm+QY+vA7oq8 X-Mailer: Evolution/1.0.2 Date: 27 Mar 2002 00:01:38 -0500 Message-Id: [EMAIL PROTECTED] Mime-Version: 1.0 --=-HiTjA4f5hm+QY+vA7oq8 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2002-03-26 at 23:37, Debian Project Secretary wrote: - - -=3D-=3D-=3D-=3D-=3D- Don't Delete Anything Between These Lines =3D-= =3D-=3D-=3D-=3D-=3D-=3D-=3D- [vote deleted] =20 - - -=3D-=3D-=3D-=3D-=3D- Don't Delete Anything Between These Lines =3D-= =3D-=3D-=3D-=3D-=3D-=3D-=3D- --=-HiTjA4f5hm+QY+vA7oq8 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8oVIyYApVP/ZmyR0RAv5pAJ4s14oMt9Hlqa/bFP0mZ5Qo/tgaUACfeSCR 3qSDTlQpg9rhhJx08Q9UuR4= =7aHi -END PGP SIGNATURE- --=-HiTjA4f5hm+QY+vA7oq8-- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: diplomacy, courtesy, and all that good stuff
On Fri, 2002-03-08 at 01:12, Branden Robinson wrote: It's never fun when a candidate has to go on the defensive, but in an effort to combat some of the FUD that a few people keep falling back upon about my colorful(?) personality, and to provide evidence supporting my assertions that I'm perfectly capable of dealing with people in a calm and polite manner, I thought I'd post some emails that I've sent in my capacity as SPI Treasurer over the past few months. (Plus one mail I received.) If any additional references to character are needed: Not only do I work with Branden at Progeny, but we shared an office for a while. I managed to not only survive the ordeal, but also maintained my employment, and we are still friends (at least, I think so :-). I have also learned a great deal from him - the virtues of StegFS being not the least of those lessons. :-) I have absolutely zero qualms about Branden's tempermental fitness for the position should he be elected. And no, he didn't ask me to post this. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: diplomacy, courtesy, and all that good stuff
On Fri, 2002-03-08 at 01:12, Branden Robinson wrote: It's never fun when a candidate has to go on the defensive, but in an effort to combat some of the FUD that a few people keep falling back upon about my colorful(?) personality, and to provide evidence supporting my assertions that I'm perfectly capable of dealing with people in a calm and polite manner, I thought I'd post some emails that I've sent in my capacity as SPI Treasurer over the past few months. (Plus one mail I received.) If any additional references to character are needed: Not only do I work with Branden at Progeny, but we shared an office for a while. I managed to not only survive the ordeal, but also maintained my employment, and we are still friends (at least, I think so :-). I have also learned a great deal from him - the virtues of StegFS being not the least of those lessons. :-) I have absolutely zero qualms about Branden's tempermental fitness for the position should he be elected. And no, he didn't ask me to post this.
