Skip to Content.
Sympa Menu

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

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: seth AT swoolley.homeip.net
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: [SM-Discuss] probst for validating vote hashes
  • Date: Sat, 20 May 2006 20:20:34 -0700

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




Archive powered by MHonArc 2.6.24.

Top of Page