I am in a group with a few dozen members. I wrote a quickie web voting system and I'm at a point where I want to add some elements of "security" to it. I'm trying to be as bare-bones as possible. What I've done is made it so that a user has to type in a secret string (e.g. GUID) when casting a vote, that I have stored in the database per voter.

The most secure means I thought of for distributing the secrets to users was to create a bunch of secrets strings in the database, print them out and bring them to a meeting, and have people draw a secret out of a hat. In that way, I believe I get two principle benefits: (1) I as the author of the voting system, would not be able to identify which individuals voted for what (nor would anyone else for that matter, only the holder of a secret can pull see / change what votes that secret is bound to), and (2) not "just anyone" could go and cast votes since the valid secrets are known a priori.

Is there a sound way of emulating that physically present, draw-from-a-hat process virtually, and without compromising the principle benefits outlined above. Maybe it can't be done and at some point there must be trust, or I have to insist on physical presence for someone to "draw" a secret (whilst I keep a record of those individuals who have been given a personal secret).

I also have no idea what to do if someone claims to have lost their secret, since if they are being dishonest and I simply have them draw a new secret, they would effectively have two votes to cast. Without a trace to what the "lost" secret was I can't go in and delete the votes associated with it if there were any.

Where I'm at is I think my best option is to basically have people draw new secrets for every vote that take place and distribute secrets through physical presence. Is there a more elegant / automated means of accomplishing the same benefits as outlined above that I'm not aware of yet?

有帮助吗?

解决方案

This is a difficult problem. Good electronic voting systems in general are a difficult problem. There is a lot of literature about them. A good place to start is to read every paper you can find by David Chaum :-)

You are tackling the secret ballot requirement.

Your system has important limitations, as you're pointed out yourself, but I don't think it's possible to do much better.

The problem is to distribute the secrets (tokens) to voters such that you, the election authority, don't know who got which secret and all the voters can believe it. That last part is the problem. A physical meeting with a hat-picking protocol does the job because voters can witness and attest to the fact that you are not cheating (looking at the secrets as they are given out). I can't imagine any protocol that allows you to be in a remote location and does the same job. For example you could generate secrets and hand them to a third party who shuffles them and gives them out to voters, but then everybody has to trust that third party. For another example you could distribute the secrets through anonymous email addresses, but then you can't ensure that only authorized voters get a secret. I see no solution here. Even the hat protocol is vulnerable unless the person holding the hat is continuously watched from the first pick until the last pick.

So the thing is, since you're meeting in person anyway, why not just conduct the vote at the same time? (Objection: it might be more convenient to meet ahead of the vote than at the time of the vote, etc...)

At least the part about the voter who loses their token is easy to answer: you can't give them a new secret. Too bad for them.

By the way, there is another requirement that you are not addressing: voter verifiability.

In your system, basic voter verifiability is quite easy: just publish all the tokens and the corresponding votes after the election. But this allows a voter to prove what their vote was to someone else (by sharing their token or making a zero-knowledge commitment for it before the election), which they're not supposed to be able to do (to prevent voter coercion and vote purchasing).

其他提示

A solution would possibly be to build a server side service that when the vote opens it automates sending a random key to each user, this is usually done with a link that has a parameter on the URL. That way when they go to the site it is anonymous, yet everyone must have a key to vote. The key both combines the topic, and the random key generated for the user in a cryptic way so it is not easily duplicated, and the key is also stored server side for validation to make sure that it is only used once. I created a polling system using this method at one point.

Drop a cookie with unique ID when they visit the site. If they clear their cookies, however, you're toast.

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top