Skip to content

Latest commit

 

History

History
32 lines (18 loc) · 7.64 KB

README.md

File metadata and controls

32 lines (18 loc) · 7.64 KB

PeaceFounder BuletinBoard

PeaceFounder BuletinBoard Audit

This bulletin board, powered by the robust PeaceFounder voting system, is meticulously designed to instil confidence in all parties. It ensures that the final tally is formed accurately, with each registered member having at most one counted vote while maintaining every member's anonymity. This system, built on stringent security measures, provides a secure environment that eliminates the need for blind trust, as everything is derived from published evidence and is E2E verifiable.

The registrar, though, needs to be audited internally, and for each successful registration, every member must send back a signed document with their registration certificate to their digital identity provider; otherwise, their membership must have been terminated promptly. (Note that if the members would publish their signed registration certificates on a public bulletin board, there would be no need for any internal audits, but that would violate the freedom of association and hence GDPR). Therefore, apart from digital identity providers or other organisational means to ensure authenticity for every member of the registrar, election results are independent. To state it differently, if all parties conspired, their best strategy to manipulate elections would result in cryptographically undisputable evidence of corruption.

Voter

As a voter, you can use the bulletin board in the following ways:

  • After the vote, check that the tree hash shown on your device corresponds to the one in the ballotbox, which is currently commit.json. Note that you may get that information announced in the newspaper or elsewhere along with the final tally in the media; thus, you would not generally need to check it here. If your device has not been compromised, that ensures that your vote is recorded and counted in the final tally (On the device, this is possible because of the counted vote bitmask that the device receives). If the tree hash does not match, you can export the commit from your local device and spread it widely as proof of corrupt authority. (Note that this is a second line of defence against partition attacks. This would generally happen automatically with the help of an anonymous channel, which ensures a globally consistent view of the ledgers).
  • You can also check that your vote is cast as intended and counted as cast to exclude any possible deception by your device that could contain malware. The unique time at which you cast a vote ensures that even if the malware had complete control of your device, it would be unable to deceive you by linking your tracking number to another person's vote who had cast the vote in the same way, eliminating many-to-one deception attacks. (Note that if there are many compromised devices and a significant number of votes delivered in a ballotbox within a short period, this does open a wiggle room for the malware to do coordinated deception. This is best in class; what can one do in such a scenario anyway? Furthermore, more complex ballots with extensive voter selection would make each ballot more unique and make coordination realistically impossible.)
  • You can also check if your vote's pseudonym had been used before or afterwards without your consent, eliminating malware which votes in place of absent voters or supersedes votes for voters that would likely not verify.

As a voter, you have the power to verify your vote at any time after the votes are published. You can also confirm that your vote is cast as intended during the vote with a tracking number shown on the screen, which can be used within a short window after you have cast your vote.

Auditor

As the auditor, you are responsible for doing the groundwork and checking that people have arrived at the same tree root on their local devices as one announced with the tally. Your work is easy because of the authority's inability to know who makes the consistency chain requests, as voters' devices make the requests over an anonymous channel. Only a few voters need to be checked, and your sample does not need to be random, either. This ensures that votes confirmed to be included are all present in the final tally.

You must also be aware of authorities that did not record valid votes. In such situations, voters can channel their votes through a proxy/monitor, which tries to ensure that the votes are included eventually. If a monitor claims that some votes cannot be included, it must be balanced with the possibility of conspiring with a minority that tries to sabotage trust. Thus, when evaluating every monitor's independence, its attempt to channel unrecordable votes through other monitors must be considered. Fortunately, such pathology is easy to spot with a critical mind in the presence of background where votes are spread between multiple monitors.

The evidence is verified, as shown by the green badge. You may fork the repository and even inspect/develop the verifier program for possible shortcomings a capable adversary could have exploited to manipulate the tally unnoticed. You may also check that every voter had a sufficient anonymity threshold so that the number of independent braiders that needed to be compromised to link voters to vote remains unattainable.

The last audit piece is internal, which verifies the honesty of the registrar. The registrar keeps records for each TicketID, which certificates are linked to authentic member identities and prove to members that those members have consented to be part of the group. The latter can be done with a document that members sign after registration that their registration has been successful. The document contains the exact invite with which the member had registered to the deme to prevent misdirection and attribution of the certificate to another group.

Coercer/Briber

As a coercer or briber, your best strategy is to make your subjects commit to coercion, as, particularly for bribery, you wouldn't want your subjects to get lucky through guessing. The proxying of the votes through you tells you only the pseudonym of the voter who cast a vote, but the vote is itself encrypted, and thus, you don't see what you are getting. Also, your subjects can revote or mark votes as invalid; that would only suffice as a commitment. Such commitment can be obtained more efficiently within an Italian attack for complex ballots or simply asking your subjects to cast an index and their alias from your subjects before votes are published, which would assure that your subjects haven't been lucky in guessing these combinations. Note the commitment phase can only be executed during the vote as after votes are published, they can deceive on what they have voted with a decoy PIN code where they can set up a desired cast record, picking the one from the list of all published votes.

After the votes are published, you can pay your dues to your subjects. You can't do it before that because voters can mark votes as coerced, which they can even do in person with a decoy PIN code or revote. You could collect your subjects before the vote starts and monitor them as they issue their first vote, which would avoid any possible revoting but would not give you assurances if the vote was valid. Therefore, you must check that your efforts have been meaningful, comparing the coerced vote tracking numbers with actual cast votes. This would impede your ability to buy the votes anonymously online as voters would not be patient enough to wait until the votes get published and would also be unable to tell if they had given up their vote for free.