Public SourceMage Discussion List

[seth AT swoolley.homeip.net]

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.

Seth

On Sat, May 20, 2006 at 08:20:34PM -0700, seth AT swoolley.homeip.net wrote:
> *** draft vote administrative policy proposal ***
> 
> Author:
> Seth Woolley
> 
> Contributors:
> Karsten Behrmann, Jeremy Blosser, Andra\305\276 Levstik, Eric Sandall, 
> Andrew Stitt
> 
> There was a long discussion in #sourcemage-admin sparked by Karsten 
> about how to avoid trusting Eric with the voting by forging hashes.
> 
> My proposed solution was to base the hash off of a source that is:
> 
> 1) known only to Eric and the voter,
> 2) ensured to be unique to the sent email and sender even if Eric were 
> complicit in attempting to forge uniqueness, and
> 3) couldn't be easily brute forced back to the vote or voter by 
> guessing plaintexts.
> 
> A hash of the pgp data itself meets these criteria because:
> 
> 1) our votes are not to be sent to the mailing list already and can be 
> encrypted to eric for stronger enforcement,
> 2) the email contents (hash), timestamp (included in the signature), and 
> private key (which encrypts the hash) all drive the signature's actual 
> contents.
> 3) the signature is encrypted which provides a lot of entropy to thwart 
> plaintext attacks on the resulting hash.  Attacking a hash via a 
> plaintext attack requires a low overall entropy -- the signature acts as 
> a very effective "salt" for our hash function.
> 
> I wrote a small bash function to calculate the hash:
> 
> probst() {
>   D="$(pgpdump -i)"
>   for i in '' $(seq 2 1000) ; do
>     echo "$D$i" | gpg --print-md sha512 | tr -d '\n ' | tr '[A-f]' '[a-f]'
>     echo
>     if [ "$1" == "$i" ]; then break; fi
>   done
> }
> 
> (Why this name for the function is left as an exercise for the reader.)
> 
> Pipe the vote into this, pass it an optional argument of '' 2 3 4, etc. 
> for how many votes are in the email if you are batching your votes, and 
> you'll get the same hash(es) Eric generates on his end (as of now).
> 
> Using a single hash for individual votes, even if batched avoids hash 
> analysis at the end of voting.
> 
> This proposal allows everybody to validate their votes on their own with 
> the hash receipt so we know Eric isn't messing with the votes.  Of 
> course, the audit provisions still stand, but this should help avoid a 
> need to invoke that.
> 
> If your messages are not clear signed, but are detached/mime signed then 
> you run this on the signature file that's created (with or without 
> combined plaintext).
> 
> This isn't intended to prevent snooping on clearsigned messages.  If you 
> want that, please clearsign your vote, then encrypt it.  This is 
> important that you do this in two steps insted of "together" for now 
> because there's now way to "decrypt" just a message and not its 
> signature if they were done together with gpg (using the gpg 
> command-line tool) and doing it in two steps makes it so the auditors 
> don't have to use the session key given by Eric to them to decrypt the 
> single message.  He can simply keep the decrypted messages together and 
> sign+encrypt them over to the auditors as one unit.  If you miss this 
> part, he'll probably just ask you to resend it so he can properly send 
> you a hash.
> 
> *** end draft vote administrative policy proposal ***
> 
> * Alternative amendment to my proposal:
> 
> Using the name of the person or thing being voted on as a uniqueness 
> salt to increase the entropy for entrance into the hash for a batched 
> vote.
> 
> I rejected this on three accounts:
> 
> 1) The name is hard to determine (utf-8 over email transports?, not 
> voting on people, but an issue?).
> 2) This means the user has to wait for the canonical plaintext after the 
> reply in many cases where it could be ambiguous to calculate the hash.
> 3) This complicates the scriptability.
> 
> * Another alternative proposal discussed:
> 
> Have the user generate their own plaintext and receipt hash however they 
> wanted to do it.  The response was that this didn't enforce anonymity 
> (although above, the users are their own enforcement as well) and could 
> be weak if the users didn't use good enough plaintexts (which invites an 
> opportunity to go after the hashes which wouldn't exist above, although 
> the response was that Eric could append data to it to increase its 
> entropy and send that one and his modified plaintext back to the user).  
> It also was said to involve more work for the user (although this is 
> debatable since the above proposal depends on users for enforcement, 
> too).
> 
> The main reason I would prefer the original proposal to the alternative 
> is that it is more defined (there's more "intervention points" in the 
> alternative).  Not for any of the reasons mentioned above, although 
> others might chime in with their own points.
> _______________________________________________
> SM-Discuss mailing list
> SM-Discuss AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/sm-discuss