David Chaum explains blind signatures in "Blind Signatures for Untraceable Payments". This is the best explanation but, since it is not available online, here is an another good explanation by Nick Szabo in
Contracts with Bearer.

"Meet the greatest simple equation since e=mc2:

gSf(m) = S(m)

S is a digital signature. f is the blinding function, and g an unblinding function. The blinding functions are usually based on a secret random number called the "blinding factor". m is another random number, a unique identifier which can, for example, refer to an instance of some object.

The idea is very clever but very simple. It may be counterintuitive because the simplest physical world metaphor of this highly useful e-commerce primitive sounds worse than useless: Alice can get Carol to sign a blank check!
Here's how:

(1) Alice generates m and blinds it. "Blinding" is just a one-time-pad encryption to oneself, f(m). She sends this to Carol. This is like taking a piece of paper and sealing it inside an envelope which Carol can't open or see through.

(2) Carol signs it: Sf(m), and sends this back to Alice. This is like Carol signing the outside of the envelope.

(3) Alice unblinds it: gSf(m) = S(m). Carol has also signed the paper Alice put inside the envelope!

The genius behind this discovery: cryptography guru David Chaum. The brilliance lies in step 3: Chaum discovered that some signatures have the property of being "commutative" with the blinding functions: Alice can strip off the blinding in the reverse order which the blinding and signature were applied, leaving just Alice's signature of n. It is as if Alice put a piece of carbon paper inside the envelope!

In particular for RSA signatures, with public key (pq, e) and private key d, the blind signature functions are the following modulo pq:

S(x) = xd
g(x) = xk-1
f(x)= xke

We can check that the blind signature property holds: gSf(m) = (m(ke))d * k-1 = md * k * k-1 = md, which is the valid RSA signature of private key d on m."

Bit Commitments

The implementation at Princeton used the Bit Commitment Using One-Way Functions described by Bruce Schenier in his book, Applied Cryptography.

• generate two random numbers
• create your message--in this case it is your voted ballot
• compute the bit commitment by hashing the two random numbers and the voted ballot.
• append one of the random numbers to the end of the hash and send it to, in this case, the tallier.
  When it comes time to reveal the content of the vote:
  
• Send the other random number and the voted ballot.
• the tallier then can compute the same hash and compare his results with the first hash you sent. If they match, the bit is valid.

A further discussion of this algorithm is at this site in Canada.

Princeton

Ben Davenport, Alan Newberger, and Jason Woodard from Princeton University have presented an election model in their paper, Creating a Secure Digital Voting Protocol for Campus Elections(no longer available). They designed their system very closely on the Fujioka, et.al., paper.

As best I can tell, they partially implemented the model in Perl using CGI with a system called E-Lect which does NOT use any cryptographic voting protocol. However one day I happened to be checking on this system and discovered that Princeton was holding student government elections. I actually went through the voting procedure to see how it worked. They are now using a system called Voce which stands for Voicing Opinions through Cryptographic Elections. This system looked as though it may have evolved from E-Lect and uses Secure Sockets. I sent email with questions to Alan Newberger but it came back so I think they have graduated.

Their model is comprised of three modules which correspond closely to the three modules in SENSUS. VOT (corresponds to Pollster) is implemented as a server, however, not a client module. For all transmissions between the three server modules, VOT, CIT (corresponds to Validator), and USG (corresponds to Tallier), PGP is used for encryption and authentication. MD5 is used for hashing and a technique based on RSA is used for blind signatures.


Fig. 2
Here is a summary of what happens when Alice casts a vote using the mode l in their paper:

• VOT computes Alice's ID field, by hashing your SS#, PAC and an election ID which is unique for this election.
  
• VOT computes the bit commitment for Alice's voted ballot.
  
• VOT blinds the bit commitment and signs it.
• VOT opens a socket to CIT and sends the bit commitment along with the ID field and signature to CIT.
• CIT recovers the blinded bit commitment by decrypting with CIT's PGP private key.
• CIT checks to see that Alice is eligible to vote by comparing her ID information with a list of eligible voters. If she is eligible, CIT checks its list of previously registered voters--the Registration File-- to ensure that a vote from Alice has not been signed.
• If everything checks out, CIT adds a record to its registration file
• CIT then applies its own signature algorithm to the bit commitment and send it back to VOT.
• VOT can recover the vote--because of the commutative properties of the blind signature algorithm--by dividing out the blinding factor to reveal the validator's signature.
• VOT writes 5 values to a key file in order to reconstruct if need be and also, in order to send Alice's voted ballot and the secret large random number to USG after USG publishes the voting results.
  • the MD5 hash of Alice's vote with 2 large random numbers
  • the unblinded bit commitment of Alice's vote signed by CIT
  • the blinding factor
  • the secret large random number used in calculating the bit commitment
  • Alice's voted ballot
• VOT sends the bit commitment and CIT's signature to USG
• USG verifies the signature of CIT, generages a unique tag number, L, and adds Alics's bit commitment and CIT's signature to his list in the Lth slot.
• USG sends acknowledgment of receipt (the bit commitment and L, the unique tag number) to VOT
• VOT Displays L to Alice so they may verify her vote in the final tally
• VOT verifies that the bit commitment received from USG is the same one it sent CIT
• VOT adds L to the record in the key file.
• When all votes are in, USG publishes the voting results in a world-readable file and requests keys from VOT
• VOT checks that each vote in the key file is also listed in the ballot box using L as an index
• VOT creates a tabulation file of (L,the unique tag number, the secret random number used in computing the bit commitment, and the voted ballot) and sends the file to USG
• USG uses the tabulation file to check each entry in the ballot box and make sure that Alice didn't change her vote.
• USG posts the final tally sheets indexed by L announcing the results of the election
• USG mails each login listed in CIT's registration file to thank them for voting

Since SENSUS and E-Lect were both based on the same model, they have basically the same strengths and weaknesses and so I refer you to that section. The one change is the "thank you" sent to each voter. Supposedly if the voter didn't vote, they would protest and that would catch any stuffing of the ballot box by the validator. That is OK for a campus election but one cannot imagine it in a large election.