edit space and blank line

Author: chenchanglew

docs/verifiability_doc.md

@@ -1,21 +1,20 @@
 # vote verifiability
 
 ## Introduction
+
 Verifiability is an important property to allows voters to check their vote has been cast unaltered, and that it has been registered correctly in the electronic ballot box.
 
 The current d-voting (version num) didn't have this design yet. The current encrypted ballot logic is shown as follows:
+
 ```mermaid
  sequenceDiagram
     autonumber
-
     participant User
     participant Backend
     participant NodeX
     participant NodeY
-
     User ->>+ NodeX: GET election info
     NodeX ->>- User: Return election info.
-
     User ->>+ Backend: POST /api/evoting/elections/<electionId>
     Note over User: data: {"Ballot": ...}
     Note over User: encrypt ballot via Elgamal encryption using electionPubKey
@@ -24,11 +23,9 @@ The current d-voting (version num) didn't have this design yet. The current encr
     Note over Backend: add userID inside payload.
     Note over Backend: sign = kyber.sign.schnorr.sign(edCurve, scalar, hash);
     Backend ->>+ NodeX: POST /evoting/elections/
-
     Note over Backend, NodeX: data: {"Payload": dataStrB64, "Signature": ""}
     Note over NodeX: verify and execute, then boardcast 
     NodeX ->> NodeY: boardcase via gRPC
-
     NodeX ->>- Backend: 200 OK text/plain
     Backend ->>- User: 200 OK text/plain
 ```
@@ -37,68 +34,62 @@ As the picture show, the Frontend will encrypt the ballot using Elgamal encrypti
 
 In this document, we aim to design an implementation to achieve verifiability of the voters' encrypted vote without leaking ballot information to others.
 
-
 ## Requirements
+
 The voter should able to verify their encrypted ballot in Frontend.
 The encrypted vote remain confidentiality from others.
 The Node shall have an endpoint to get voter encrypted ballot.
 
-
 ## Related work
 
 ### Strawman approach
+
 The strawman design is just using a fixed seed to encrypt the ballot which make the encrypted ballot deterministic. Then the user can verify the encrypted ballot on the chain by just encrypt a new ballot with the same option.
 
 However this design actually will break the confidentialy property of our d-voting system. An adversary be able to decrypt the user's ballot by recording the ciphertext of the encrypted ballot in every possible choice. Then the adversary can just check the ciphertext on the chain and will notify the voter ballot.
 
 Thus we should keep some secret only to the voter himselves or the backend to prevent adversary unlock the ballot.
 
 ### Swiss POST evoting system
+
 Swiss POST implement their own [evoting system](https://www.evoting.ch/en) which support the verifiability of the casted ballot.
 
 Their protocol takes place between a User, a trusted device, and an untrusted device. In this example the user will be Alice, the trusted device will be her cellphone, and the untrucsted device will be the evoting backend system. After casting the vote, user will received a encBallotReport (via QR code). Then the user can verify if their vote has been cast correctly or not.
+
 ```mermaid
 sequenceDiagram
     autonumber
-
     participant User
     participant TrustedDevice
     participant Backend
     participant Node
-
     User ->>+ TrustedDevice: cast vote
     TrustedDevice ->>+ Backend: plain ballot
     Note Over Backend: Generated random voteID, use it as RNG to generate encBallotReport.
     Backend ->> Node: Send encBallotReport to NodeNetwork
     Backend ->>- TrustedDevice: encBallotReport + voteID
     TrustedDevice ->>- User: show encBallot Report (via QR code etc)
-
     Note Over User: Use the voteID and verify the encBallotReport
     Note Over User: verify via Hash of report etc.
-
 ```
 
-
 ## Proposed solution
+
 According to our requirements, we assume that the frontend is trusted. If frontend is compromised, the adversary can already know the plaintext of the ballot which breaks the confidentiality of the ballot.
 
 When the frontend after the frontend encrypted the ballot (use default non-deterministic encryption), it can hash the encrypted ballot and show the hash str of the encrypted ballot. The frontend sends the encrypted ballot to the backend.
 
 A user can then check the hash of the vote by looking at the details of the form if the hash of the vote matches the one he received.
 
-
 ```mermaid
 sequenceDiagram
     autonumber
-
     participant User
     participant Backend
     participant NodeX
     participant NodeY
-
     User ->>+ NodeX: GET election info
     NodeX ->>- User: Return election info.
-
     User ->>+ Backend: POST /api/evoting/elections/<electionId>
     Note over User: data: {"Ballot": ...}
     Note over User: encrypt ballot via Elgamal encryption using electionPubKey
@@ -108,14 +99,11 @@ sequenceDiagram
     Note over Backend: add userID inside payload.
     Note over Backend: sign = kyber.sign.schnorr.sign(edCurve, scalar, hash);
     Backend ->>+ NodeX: POST /evoting/elections/
-
     Note over Backend, NodeX: data: {"Payload": dataStrB64, "Signature": ""}
     Note over NodeX: verify and execute, then boardcast 
     NodeX ->> NodeY: boardcase via gRPC
-
     NodeX ->>- Backend: 200 OK text/plain
     Backend ->>- User: 200 OK text/plain + voteSecret
-
     User ->>+ NodeX: get form details 
     NodeX ->>- User: return form details and hash of encrypted vote.
     Note over User: check the hash of the vote is the same or not.
@@ -124,6 +112,7 @@ sequenceDiagram
 However, this design is still not perfect because it didn't have coercion resistance property because coercers will know the Hash of encrypted ballot during the vote. We can achieve coercion resistance via moved the encryption process to the backend and use benaloh challenge protocol to encrypt the vote. But currently our system didn't require coercion resistance thus we will not implement this.
 
 ### frontend
+
 - Edit the submit vote function
     - hash the encrypted ballot and show to the user.
 - Edit form details page to show the hash of ballot.
@@ -132,26 +121,26 @@ However, this design is still not perfect because it didn't have coercion resist
     - User can check if the hash they received is the same as the hash on the details.
 
 ### Blockchain node
-- edit api "/evoting/forms/{formID}", add the hash of the ballot to the form structure.
 
+- edit api "/evoting/forms/{formID}", add the hash of the ballot to the form structure.
 
 ## Extension coercion protection
+
 Here we proposed a solution to protect against coercion. However, this will not be implemented because it will need to change most of the current architecture. We will implement the Benaloh challenge in this design.
 
 ### Benaloh Challenge
+
 [Benaloh Challenge](https://docs.rs/benaloh-challenge/latest/benaloh_challenge/) (also known as an Interactive Device Challenge), a crytographic technique to ensure the honesty of an untrusted device. While orignially conceived in the context of voting using an electronic device, it is useful for all untrusted computations that are deterministic with the exception of using an RNG. Most cryptography fits in this category.
 
 This protocol takes place between a user, a trusted device, and an untrusted device. In this example the user will be Alice, the trusted device will be her cellphone, and the untrusted device will be a voting machine. The voting machine needs to do some untrusted computation using an RNG (encrypting Alice's vote), the details of which need to be kept secret from Alice so she can't prove to a 3rd party how she voted. However, the voting machine needs to assure Alice that it encrypted the vote correctly and didn't change her vote, without letting her know the secret random factors it used in it's encryption.
 
 ```mermaid
 sequenceDiagram
     autonumber
-
     participant User
     participant TrustedDevice
     participant Backend
     participant Node
-
     User ->>+ TrustedDevice: marks ballot
     TrustedDevice ->>+ Backend: plain ballot
     Note Over Backend: Encrypted her marked ballot (using random factors from an RNG)
@@ -160,10 +149,8 @@ sequenceDiagram
     TrustedDevice ->>- User: show Report (via QR code etc)
     Note Over User: if user decide to "cast", process is done
     Note Over User: if he/she choose challenge, she can scan the QR (hash of encVote) and select challenges.
-    
     TrustedDevice ->>+ Backend: send challenge request
     Backend ->>- TrustedDevice: give the marked-ballot and random factors RNG.
-
     Note Over User, TrustedDevice: checks commitment by re-computing commitment using markedBallot & RNG
     Note Over User, TrustedDevice: if different, Backend is compromised
     Note Over User, TrustedDevice: if same, return to step 1, (remark ballot)