Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] probst for validating vote hashes

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Jeremy Blosser <jblosser-smgl AT firinn.org>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] probst for validating vote hashes
  • Date: Sat, 20 May 2006 23:11:06 -0500

On May 20, seth AT swoolley.homeip.net [seth AT swoolley.homeip.net] wrote:
> I should have given an example of how the current system is broken:
>
> assigned hash by Eric published hash:
> voter A votes yes dfdfsd yes: dfdfsd
> voter B votes yes dfdfsd yes: ofkjdf
> voter C votes no kflsdf yes: lgkgfd
> voter D votes no kflsdf yes: pfskff
> voter E votes no kflsdf no: kflsdf
> voter F votes no kflsdf no: ijfdks
>
> actual vote: 4 no, 2 yes
> published vote: 2 no, 4 yes
>
> People aren't supposed to share any part of their hashes or reveal their
> vote which has been published, so they wouldn't know about the identical
> hash deception unless an audit were to occur.

This is a good example of the noted attack, but if I may provide a
(hopefully) simpler statement of the solution:

The existing policy allows the vote counter (who doesn't necessarily have
to be Eric) to assign the 'receipt string' via whatever means they choose.
This results in the above-noted attack possibility.

To fix this, we need to require that the receipts be generated in a way
that has the properties Seth noted, which I'll rephrase as:

1) known ahead of time to the voter (so the voter can derive it themselves,
without the counter even being involved)
2) unique per individual vote cast (so the voter knows the above attack did
not occur)
3) irreversible (so that when the receipts are published they can't be
cracked to see what voter+vote the represent)

We went around a few possibilities on this, then noted that a hash of the
already-present GPG signature of the vote has all of these properties. We
can't use the signature directly, because you can tell from the sig which
key was used to create it. But a hash of the sig is irreversible (with
modern math, anyway) and unique. And since it's based on the sig the voter
creates, they know how to create it themselves. As an added bonus the
signature is already present so this doesn't require us to really change
anything about how we submit our votes.

The one remaining nit was that we sometimes do batched votes, like we're
doing right now. In this scenario we need to be able to generate a receipt
per vote, so that people can't tell from the published results that a
certain person voted for A and B but not C and perhaps from that figure out
who that person is. It was noted that just adding a serial number to the
signature before taking the hash would create a unique hash per vote, and
as long as the serial method is defined ahead of time the voter still can
predict the hash.

The function Seth included does all of this. The most likely path forward
will be to amend the policy docs to stipulate that that function be used to
generate the receipts. Nothing else about the vote process needs to
change.

Is this all clear enough (to those that care)? If you don't care, you
don't really need to worry about it... at the worst you need to note that
if you want to encrypt your votes when you send them you should sign them
BEFORE you encrypt them, because we need the signature separately to
generate this receipt/hash.

Attachment: pgpEMjrt4PNqi.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page