Re: Spec for anonymous voting

[Dave Neary <dneary free fr>]

Hi,

James Henstridge a écrit :
> > From my reading of the document, the intent was to encrypt the hash, and
> use the encrypted hash as the token.

That's the intention, yes.

> In fact, it seems less anonymous than randomly generated tokens:

That's correct too :)

I can explain how that happened, though.

We started off with the assumption that you shouldn't store name/token 
pairs. So we needed a way to deterministically generate tokens with a 
trap-door which could only be opened by the election committee (hash + 
encryption).

But then we needed (or do we?) a way to generate the list of voters. 
This information is typically public for public elections, for example. 
And to do that you need to mark people off as they vote. So you need to 
store name/token pairs. But then the whole point of hash/encryption is 
gone, and you're as well off just storing name/randomly generated token.

If you're afraid that the database could be compromised, you can then 
encrypt the token before sending it.

> assuming the tokens are published along with the election ballots (which
> would be required in order for a member to verify their vote), you could
> find out how someone voted by doing the following:
>
>    1. hash their (firstname, surname, email) triple
>    2. decrypt all the voting tokens using the election committee public key
>    3. see which voting token matches the hash

Yes, you could. Big hole I didn't see. Random tokens are better.

Cheers,
Dave.

PS. James, do you have any time to take this on? (in case anyone failed 
to notice, I'm not planning on doing it, and want someone to volunteer).

--
David Neary
bolsh gimp org