Re: Concerns about the election process

On Sat, 2006-11-25 at 21:40 -0500, Ryan Lortie wrote:

This falls under the category of "concerns about the election process".
It's a bit of a nit-pick.

I'm writing about two concerns.  The two concerns are secrecy of the
vote (nobody can discover who I voted for) and security of the vote
(nobody can tamper with the results without being discovered).


I will first discuss security.  This issue is easy to fix and should be
fixed for the next elections.

It is clear that an attempt has been made toward security.  The use of
anonymous tokens are provided to allow each concerned voter to be sure
that their vote has been counted properly.

  - step 4 is a confirmation that your vote has been accepted and gives
    you the anonymous token that will enable you to verify your vote.

This is insecure.

As a voter, how do I know that my "token" isn't just a deterministic
hash of my choices?  The people running the election could then easily
just publish my choices along with this token once for every person who
chose the same way that I did.  Essentially, I don't know if my vote is
really my vote at all, so I have no reason to believe that my vote has
been counted.
Hashes are not created with your choices. It's a random hash which is
used for voter to check his/her vote after results are announced. It's
only the voter who knows that the hash depends on him or her. Apart from
that even memberhip-committee members has no way to know that ie. Ryan
has this hash. 

The only way of discovering this would be to talk with others about my
choices and even then it's only a single collision which could easily be
put off as voter error.  Discovering the corruption of those holding the
voting process would require a massive public disclosure of who everyone
voted for.
After results are announced, there will be a page listing all votes
counted with hashes and votes used with that hash. Since you had already
noted your hash somewhere, you will be able to check if your vote is
counted and has correct votes. If not you can challenge elections.  

All reasonably secret voting systems must dismiss single users claiming
errors (since otherwise someone could change their mind and cause the
election to be held again).  It should take a large number of people
claiming inconsistencies in order for real doubt to be cast on the
Once you have voted you can't change your vote. And your vote token is
not valid anymore. If you believe that you did not vote and your token
is invalid, you can contact elections gnome org to report this issue. 

Now of course, I trust those running the elections.  It's just that if
you are going to go to the effort of attempting to prove that the
process is secure against tampering then you should actually prove it.

A secure process would be to allow the voter to provide their own
anonymous token.  This token could be any string or could be limited to
a hexadecimal number of an exact (reasonable) size.  To make the process
easier, a Javascript "Generate" button could be used to generate this
random number.  The source of the Javascript could be inspected, and for
the truly paranoid there would still be the possibility of entering your
own token.
The thing is, process of creating voting tokens are similar, that token
is created by automatic script on server elections run. But there's no
connection b/w this token and your vote. That token just enables system
to let a specific email to be able to vote and its use ends there. By
making voters to create their own token to vote, we have to store e-mail
addresses which has voted, which is less secure I guess. If you can
elaborate more on it, I think I can respond better. 

The voter could then be sure that with a vanishingly low chance of a
collision, that their vote is in fact their vote.
Hashes are randomly generated md5 hashes, and collisions are really less


The second problem is secrecy.  This problem is a lot more difficult to
fix in a reasonable manner and maybe should not be fixed at all.  The
problem stems from the fact that the voting web application could
trivially be augmented to create a log of each voter and their choices.
It does not log voters, it just logs hashes as I stated above. It has to
keep votes somehow to count it, though.

A possible workaround for this limitation is the idea of a
blinded-signature scheme.  Under this scheme, it is possible to have an
entity sign a document without being able to view it.  The voting
process then proceeds something like this:

A voter generates a random voting token of a specific format (in this
case, it would likely be the same random token as used in the vote
security process outlined above).  They "blind" this token and send it
along with traditional credentials (like email address and voting key,
or possibly PGP signature from their email address) to a ballot signing
authority.  The ballot signing authority ensures that this is the only
signing request that the user has made, signs their ballot and returns
it to them.
Agreed, however this puts more technical barrier to vote, which might
cause some not being able to vote at all. I'm totally into using PGP
keys to authorize members, e-mail is insecure for that, but we currently
just "trust". Sometime in future we should lower this barrier with some
tools and switch to PGP keys, as cvs accounts switched. 

The token is of a specific format to prevent certain types of attacks in
which it might be possible (depending on the blinding scheme used) to
obtain a signature that is valid for multiple messages.

The signing authority can log all of the ballets that it has signed (and
in fact it probably should, to allow recovery of lost ballots). 

The voter then "unblinds" their ballot, receiving their original voting
token.  They vote with this token.  The election is held by possibly the
same person who did the blind signature.

Because of the blinding process, it is possible for the people holding
the elections to ensure that the ballot is legitimate but absolutely
impossible to link it with a specific person.  The people holding the
election record each unique token used to vote in order to ensure that
multiple voting does not occur.

I've been intentionally vague about the specific algorithms used to do
blind signatures because there are a lot of them.  The entire process is
also explained in much more detail here:


These are my two concerns.  Please take the first half of this email
very seriously and the second half as a pie-in-the-sky idea that might
be nice eventually if somebody has a lot of time.  It's only recently
that GNOME has had anonymous voting at all, so voter secrecy is a
somewhat less important issue than the security of the vote.

I'd like to take a moment here to acknowledge Baris and everyone else
who has been involved in the election process this year.  Thanks guys.
Without you, there wouldn't even be a vote to speak of.
Thanks you very much for your feedback, be sure that it will be taken
into consideration. 

membership-committee mailing list
membership-committee gnome org

Attachment: signature.asc
Description: This is a digitally signed message part

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