# PVPBC: Privacy and Verifiability Preserving E-Voting Based on Permissioned Blockchain
## 6 PVPBC Protocol: Cryptographic Considerations
### Election Phase  
**Voting:** After gaining access to the voting site, the voter engages with the voting page, which is part of the front-end system, to cast their ballot. The PVPBC front-end system encrypts the cast ballot using the election key, and then signs the encrypted ballot using the voter's signing key. Then, the front-end system submits the ballot, \(V_{i}\), to the authentication server at the EA using an authenticated communications channel.  
If a ballot is received by the authentication server, and it has the correct format -the ballot is tagged with the correct election identifier-, an acknowledgement is sent as a response by the EA, which consists of a signature applied to the ballot \(V_{i}\). If the ballot does not conform to the correct format, the EA does not output anything. If the voter or front end tries to vote more than once and an acknowledgement has already been issued by the EA, then the EA reissues the initial acknowledgement and does not consider the new vote. After this set of events, the encrypted vote is published to the permissioned DL alongside the encrypted tracking number, voter's public key, and trapdoor commitment. This is the public record of votes received in encrypted form. This means the signed encrypted vote is created at the vote time, and posted on the WBB when it is cast. Carrying out elections using this process results in the provision of public, real-time information regarding the turnout for the election. The voter is not involved with the voter-side cryptographic actions of the Selene protocol in the voting phase. Instead, the voter's task during the voting phase is to create and cast a ballot in the usual way.  
**Voting-phase technical details:** After casting the ballot, the front-end system carries out several steps to produce the final result. For each cast ballot:  
1. The ballot is encrypted and signed, obtaining \[V_{i}=sign_{v_{i}}(\{Vote_{i}\}_{PK_{T}}).\] (4)
2. A non-interactive zero-knowledge proof of the knowledge of the plaintext is created, \(\Pi_{i}\), and it is attached to the encrypted ballot. In addition, this proof also includes the voter's verification key, aiming to ensure the proof is valid only for this verification key. \[V_{i}=sign_{v_{i}}(\{Vote_{i}\}_{PK_{T}}),(\Pi_{i}).\] (5)
3. The front end, \(V_{i}\), submits vi's ballot to the authentication server, EA, using an authenticated channel alongside the voter's VID. If the ballot is correctly formed, then the EA signs the ballot and sends the ballot back to the front-end system.
4. The signed encrypted ballot and the NIZKP are posted on the ledger alongside the previously published encrypted tracking number, tracking number commitment, and voter's identity (\(PK_{i}\)). This process is defined mathematically in \[(vk_{i},PK_{i},\{g^{n_{\pi(i)}}\}_{PK_{T}},\beta_{i},sign_{v_{i}}(\{Vote\}_{PK_{T }}),\Pi_{i}).\] (6) This is the only information published on the ledger. It is important to note that the standard voting information collected by the election system is not published.