Read Section 6.1: Secure Elections in Applied Cryptography, 2nd Edition, by Bruce Shneier, 1996. This project implements the secure election protocol for Voting with Two Central Facilities described in this document. (You may find the document in Kit.) The implementation will provide a secure way for people to vote online, which eliminates the hassle of physically being present at designated election locations. Since computerized voting will not replace general elections unless there is a protocol that both maintains individual privacy and prevents cheating, the ideal protocol must meet these requirements:
- Only authorized voters can vote.
- No one can vote more than once.
- No one can determine for whom anyone else voted.
- No one can duplicate anyone else's votes.
- No one can change anyone else's vote without being discovered.
- Every voter can make sure that his vote has been taken into
account in the final tabulation.
And sometimes: - Everyone knows who voted and who didn't.
Your design should use two central facilities: Central Tabulating Facility (CTF) and Central Legitimization Agency (CLA). CLA's main function is to certify the voters. Each voter will send a message to the CLA asking for a validation number, and CLA will return a random validation number. The CLA retains a list of validation numbers as well as a list of validation numbers' recipients to prevent a voter from voting twice. Then, the CLA completes its task by sending the list of validation number to the CTF. CTF's main function is to count votes. CTF checks the validation number against the list received from the CLA. If the validation number is there, the CTF crosses it off (to prevent someone from voting twice). The CTF adds the validation number to the list of people who voted for a particular candidate and adds one to the tally. After all the votes have been received, the CTF publishes the outcome.
Your program should create a simulation of this protocol, in which the election runs for a given amount of time, and users communicate with the CLA and CTF by means of some user interface, or the command line. Of course, all messages passed between the various parties should be encrypted and signed, to prevent someone from impersonating someone else or intercepting transmissions. Encryption should be done using AES (with CBC or CTR mode) and signing should be done using RSA. You may work in groups (2-3 would be a good size, 4 often gets too hard to coordinate and manage). You may want to consider choosing members of your group based on more than just who you are friends with since you all have different experiences to contribute - some of you are better at understanding specifications and translating them into algorithms to be coded, some of you are better at testing code, some of you may never be able to find times to meet, etc.
Your program should be well-documented, which includes, but is not limited to:
- Program documentation: name(s) of group members, program description, purpose, etc, at the beginning of each file,
- Comments before every function,
- Comments inside more complex functions that need explanations.
Programs are due on Kit by 11:59 PM on Tuesday, March 15, 2022.