Re: Spec for anonymous voting


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.


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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]