Hi Baris. Thanks for your quick reply. I just want to address some issues brought up in your email to make my point more clear. I want to state again that I have faith in the fair (both secret and secure) running of the elections by the current committee. The purpose of my email is to harden the measures that the committee is using to outwardly prove the security of the process. Again for emphasis: I have confidence that the way the elections are current held is absolutely fair. This confidence, however, is a matter of faith and it doesn't have to be. There exist methods by which an absolutely paranoid voter can be convinced (without trusting anyone at all) that the elections are secret and secure. These methods make the election process almost entirely transparent while still preserving anonymity. These are the methods I've been writing about. On Sun, 2006-26-11 at 16:09 +0200, Baris Cicek wrote: > On Sat, 2006-11-25 at 21:40 -0500, Ryan Lortie wrote: > > As a voter, how do I know that my "token" isn't just a deterministic > > hash of my choices? The people running the election could then easily > > just publish my choices along with this token once for every person who > > chose the same way that I did. Essentially, I don't know if my vote is > > really my vote at all, so I have no reason to believe that my vote has > > been counted. > Hashes are not created with your choices. It's a random hash which is > used for voter to check his/her vote after results are announced. It's > only the voter who knows that the hash depends on him or her. Apart from > that even memberhip-committee members has no way to know that ie. Ryan > has this hash. I trust that hashes are currently created randomly but the point is that I have no way to know this for sure (other than taking you at your word). > > The only way of discovering this would be to talk with others about my > > choices and even then it's only a single collision which could easily be > > put off as voter error. Discovering the corruption of those holding the > > voting process would require a massive public disclosure of who everyone > > voted for. > After results are announced, there will be a page listing all votes > counted with hashes and votes used with that hash. Since you had already > noted your hash somewhere, you will be able to check if your vote is > counted and has correct votes. If not you can challenge elections. This is fine, but unless I know for sure that my hash is random, I don't know that the vote I see listed on the results page is actually mine and mine alone. > > All reasonably secret voting systems must dismiss single users claiming > > errors (since otherwise someone could change their mind and cause the > > election to be held again). It should take a large number of people > > claiming inconsistencies in order for real doubt to be cast on the > > process. > Once you have voted you can't change your vote. And your vote token is > not valid anymore. If you believe that you did not vote and your token > is invalid, you can contact elections gnome org to report this issue. But if a single voter claims "my vote was not correctly recorded" in the absence of such reports from other voters the community as a whole will more or less conclude that that single voter made a mistake (or is lying). This is fine, of course, since otherwise the entire process could be brought down by a single malicious voter who always claims that their choice was not properly recorded and demands a reelection. > > A secure process would be to allow the voter to provide their own > > anonymous token. This token could be any string or could be limited to > > a hexadecimal number of an exact (reasonable) size. To make the process > > easier, a Javascript "Generate" button could be used to generate this > > random number. The source of the Javascript could be inspected, and for > > the truly paranoid there would still be the possibility of entering your > > own token. > The thing is, process of creating voting tokens are similar, that token > is created by automatic script on server elections run. This is exactly my point. The two systems we are describing are almost exactly the same. The only difference is that my process is more transparent to the voter. Currently, I have no way to know what my token is other than to believe your claim that it is "random". If I am allowed to submit my own token then I know exactly what it is, because I generated it. I could possibly use this process to give away my anonymity by encoding "my name is ryan" into my token, but really, there are much easier ways for me to sacrifice my anonymity. The use of Javascript on the voting page to generate tokens would make this process easier for those who do not wish to generate their own tokens. Even still, the Javascript method is more transparent since I don't have to take your word that the tokens are generated randomly. I can "view source" of the web page and look at the algorithm for myself. > But there's no connection b/w this token and your vote. That token > just enables system to let a specific email to be able to vote and its > use ends there. By making voters to create their own token to vote, we > have to store e-mail addresses which has voted, which is less secure I > guess. If you can elaborate more on it, I think I can respond better. This statement is absolutely not true. You store no additional information about the voter. You store only their vote and the token that they created (in place of the token that you would normally create). The only difference is that you accept the token as part of the HTTP POST instead of randomly generating it in your script. What you record in the election log is absolutely the same as what you record now -- it just comes from a different place. > > The voter could then be sure that with a vanishingly low chance of a > > collision, that their vote is in fact their vote. > Hashes are randomly generated md5 hashes, and collisions are really less > likely. Again, true... but as a paranoid voter, I don't know this. :) > > The second problem is secrecy. This problem is a lot more difficult to > > fix in a reasonable manner and maybe should not be fixed at all. The > > problem stems from the fact that the voting web application could > > trivially be augmented to create a log of each voter and their choices. > It does not log voters, it just logs hashes as I stated above. It has to > keep votes somehow to count it, though. I have to trust you when you say this. I have no way to know for sure. > Agreed, however this puts more technical barrier to vote, which might > cause some not being able to vote at all. I'm totally into using PGP > keys to authorize members, e-mail is insecure for that, but we currently > just "trust". Sometime in future we should lower this barrier with some > tools and switch to PGP keys, as cvs accounts switched. PGP actually isn't required here -- it could only serve as a possible alternative to password login. In any case, however, some sort of RSA use on the part of the user is required in order to participate in the blind signature process. This is exactly the reason why the 2nd part of this email is pie-in-the-sky. I'm not going to spend any more time talking about it. I think the first part is higher priority because it can be easily fixed. :) Cheers
Attachment:
signature.asc
Description: This is a digitally signed message part