Public SourceMage Discussion List

[Eric Sandall <eric AT sandall.us>]

-----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-----