Public SourceMage Discussion List

[Robin Cook <rcook AT wyrms.net>]

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