# PVPBC: Privacy and Verifiability Preserving E-Voting Based on Permissioned Blockchain
## 6 PVPBC Protocol: Cryptographic Considerations
### Pre-Election Technical Setup
The resulting shuffled list is then assigned to the voters, so that each voter is associated with a unique secret encrypted tracker, \(\{g^{n_{i}(i)}\}_{PK_{T}}\), where \(\pi\) is the permutation induced by the shuffle. At this junction, the calculation of trapdoor commitments that open for a unique tracker occurs. The procedure by which the tracking-number commitment for each voter is generated is outlined. 1. A random number, \(r_{i}\), is generated for each voter, \(i\), by summing random values, \(r_{i,j}\), which were generated by each teller, \(j\), for voter \(i\), where, \(r_{i}=\Sigma_{j=1}^{i}r_{i,j}\). 2. The product, \(\{PK_{i}^{r_{i}}\}_{pk_{T}}\), is generated using the component which is generated by each teller, \(j\), \(\{PK_{i}^{r_{i}}\}_{pk_{T}}\), and then by taking the product of these components. Similarly, \(\alpha_{i}=g^{r_{i}}\) can be computed in a distributed fashion. The value, \(\alpha_{i}=g^{r_{i}}\), will not be published, but it will be communicated privately to voters at the end of the election. In the PVPBC voting system, it is not computed until the end of the election. 3. The product of \(\{PK_{i}^{r_{i}}\}_{pk_{T}}\) and \(\{g^{n_{i}(r_{i})}\}_{pk_{T}}\) is computed to obtain \(\{PK_{i}^{r_{i}}\cdot g^{n_{i}(r_{i})}\}_{pk_{T}}\). 4. Threshold decryption is applied to reveal the commitment \(\beta_{i}=PK_{i}^{r_{i}}\cdot g^{n_{i}(r_{i})}\). The commitment \(\beta_{i}\) is published. The initialization block, which acts as the genesis block for the chain, is used to initialize the DL in the front-end of the PVPBC voting system. This block does not contain  
Figure 7: The voter-registration phase is managed by the TTP by making use of a permissioned DLT and smart contract. votes. All of the election information, for example, the election public key, the set of valid choices the voters can choose, are included. As a result, a DL is linked to a specific election. As the system parameters are integrated into the DL, potential disagreement over the system parameters is prevented. To allow trustees to join the permissioned network and to participate in maintaining the DL, security credentials are generated for them. A tuple of terms is posted to the DL for each voter \(V_{i}\), before the voting phase starts, in the following manner:  
\[(vk_{i}\,\ PK_{i}\,\ \{g^{n_{\pi(i)}}\}_{PK_{T}}\,\ \beta_{i}). \tag{2}\]  
**Election-key generation:** In the PVPBC front-end system, tellers are responsible for generating the threshold election key, \(PK_{T}\). This is the same in the Selene protocol. The election public key, \(PK_{T}\), is created in a distributed way by the election tellers using the key-generation protocol proposed by [PERSON] in [33]. In this protocol, every teller \(T_{j}\) has a share \(s_{j}\in Z_{q}\) of a secret S.  
As the values \(PK_{j}=g^{s_{j}}\) are made public, every teller is committed to these values. The encryption key, \(PK_{T}\), for the election is computed using  
\[PK_{T}=\Pi_{j=1}^{n}PK_{j}, \tag{3}\]  
where \(n\) is the number of tellers. All tellers are sent the calculated encryption public key, \(PK_{T}\). It is not possible for a single teller to recover the secret key, \(S=\sum_{j=1}^{n}s_{j}\). The authentication server, which is run by the EA, runs the key-generation algorithm of the digital signature scheme to produce the authentication server's public/private (verification/signing) keys. The primary action that takes place during the election phase, e.g., voting, is now described.