Public SourceMage Discussion List

[seth AT swoolley.homeip.net]

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