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: Eric Sandall <eric AT sandall.us>
  • To: SM-Discuss <sm-discuss AT lists.ibiblio.org>
  • Subject: Re: [SM-Discuss] probst for validating vote hashes
  • Date: Sat, 20 May 2006 21:25:29 -0700

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jeremy Blosser wrote:
> 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.

Clear as mud. :) For the majority of people (basically everyone except
the vote counter and those wishing to encrypt their votes (so far only
one)) voting will stay the same.

- -sandalle

- --
Eric Sandall | Source Mage GNU/Linux Developer
eric AT sandall.us | http://www.sourcemage.org/
http://eric.sandall.us/ | SysAdmin @ Shock Physics @ WSU
http://counter.li.org/ #196285 | http://www.shock.wsu.edu/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEb+u5HXt9dKjv3WERAhQZAKCpYschQBMihrIcV1kFyj2j02G+/ACdFfez
/ZtIVMBCWRhAqNciVltf2/A=
=DKej
-----END PGP SIGNATURE-----




Archive powered by MHonArc 2.6.24.

Top of Page