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
[EMAIL PROTECTED]
_______________________________________________
foundation-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/foundation-list
