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: Robin Cook <rcook AT wyrms.net>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] probst for validating vote hashes
  • Date: Sun, 21 May 2006 10:06:42 -0500

This seems to make voting more difficult and too many steps to me.

CuZnDragon
Robin Cook

On Sat, 2006-05-20 at 20:20 -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
>

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




Archive powered by MHonArc 2.6.24.

Top of Page