rehash on vote procedure amendments

[Ryan Lortie <desrt desrt ca>]

Hello

Last year I wrote an email to the foundation-list and elections@
explaining a couple of my concerns with the current election process.

Baris has asked me to write the list (and specifically to you, Vincent)
to revive discussion of this topic in hopes of integrating some of the
improvements for this year's elections.

My concerns are not that the election process is not anonymous or
secure, but that as a voter, I currently have no hard guarantee of that
fact.

The original post and the following discussion is here:

http://mail.gnome.org/archives/foundation-list/2006-November/msg00137.html

The two specific problems are that:
  1) I can't be sure that my vote was counted.
  2) I can't be sure that the vote was truly anonymous

Problem 2 is relatively difficult to fix, but at the time I discussed
some ideas with Behdad and hacked together a prototype of what a
solution to Problem 1 might look like.

I was going to turn this into a whole new voting system; I even designed
a DB schema for it.  I then realised that this is rather silly when we
have the current voting system.  It's much easier to just integrate
these ideas into that one.

Here's a link to the hack-up I made:

http://desrt.mcmaster.ca/code/vote/

You should start at "start.php" and each php file is available for
download (as the corresponding .phps file).

The procedure works something like this:

1) The user logs in, etc.
2) The voting page is presented with a list of possible candidates.
3) The user checks off the candidates they want.
4) The user generates or provides some random data (or simply accepts
the random data that's already there).
5) The user checks that their voter information blob is of this form:

   rupert gnome org:1,3,6:sdjfsdfs

where the first part is their email address, the middle part are the
numbers of the candidates that they voted for and the end part is the
randomness that they generated or provided.

6) The user checks that their voter information blob hashes to their
vote token (simple SHA1).

Using this method of generating the vote token has two advantages over
the current system:

1) By containing their email address and selecting their own random
data, voters can be absolutely sure (up to the point of SHA1 hash
collisions) that their voter token belongs to them (and wasn't issued to
two separate people who voted for the same candidates).

2) An additional level of traceability is provided -- if when the
results are published, the list of candidates that the user voted for
isn't what the user thinks that they voted for then they can prove this
by producing their voter information blob which hashes to the published
token.  Since this blob contains their email address and the list of
candidates that they really voted for and hashes to the token published
on the results page, they have proof that their challenge to the results
is legitimate.

It's possible to satisfy these 2 points without the use of random data.
If we do this, however, we permit the hashes to be easily reversed
(since the search space would become merely a person's email address and
the small possible number of combinations of votes).  This means that
the vote is, effectively, no longer anonymous.

A nice additional feature that I didn't implement at the time would be
if the voting server provided the voter with a message of the following
form at vote time (using some "vote server" private key):

---begin pgp message---
The following vote has been cast in the 2007 board election:

cf1c03f7a3ff0dfc2c7fb69e5db615f70348b9bc
---end pgp message---
---begin signature---
blah blah blah
---end signature---

This would allow the user to protest the case where their vote doesn't
appear at all on the results page.

That is all :)

Cheers