Skip to content

Commit da1cff9

Browse files
chenchanglewchenchanglew
committed
create verifiability docs
1 parent 0f99cbf commit da1cff9

File tree

1 file changed

+173
-0
lines changed

1 file changed

+173
-0
lines changed

‎docs/verifiability_doc.md

+173
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,173 @@
1+
# vote verifiability
2+
3+
## Introduction
4+
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.
5+
6+
The current d-voting (version num) didn't have this design yet. The current encrypted ballot logic is shown as follows:
7+
```mermaid
8+
sequenceDiagram
9+
autonumber
10+
11+
participant User
12+
participant Backend
13+
participant NodeX
14+
participant NodeY
15+
16+
User ->>+ NodeX: GET election info
17+
NodeX ->>- User: Return election info.
18+
19+
User ->>+ Backend: POST /api/evoting/elections/<electionId>
20+
Note over User: data: {"Ballot": ...}
21+
Note over User: encrypt ballot via Elgamal encryption using electionPubKey
22+
Note over User, Backend: data = encrypted ballot
23+
Note over Backend: check role and sign payload.
24+
Note over Backend: add userID inside payload.
25+
Note over Backend: sign = kyber.sign.schnorr.sign(edCurve, scalar, hash);
26+
Backend ->>+ NodeX: POST /evoting/elections/
27+
28+
Note over Backend, NodeX: data: {"Payload": dataStrB64, "Signature": ""}
29+
Note over NodeX: verify and execute, then boardcast
30+
NodeX ->> NodeY: boardcase via gRPC
31+
32+
NodeX ->>- Backend: 200 OK text/plain
33+
Backend ->>- User: 200 OK text/plain
34+
```
35+
36+
As the picture show, the Frontend will encrypt the ballot using Elgamal encryption which has a nondeterministic result, and then sends it to the Backend to verify and sign. After that, the backend will send the encrypted + signed ballot to the blockchain node to put it on the chain. However, since the encryption is nondeterministic thus the user will not able to verify their casted ballot stored in the node.
37+
38+
In this document, we aim to design an implementation to achieve verifiability of the voters' encrypted vote without leaking ballot information to others.
39+
40+
41+
## Requirements
42+
The voter should able to verify their encrypted ballot in Frontend.
43+
The encrypted vote remain confidentiality from others.
44+
The Node shall have an endpoint to get voter encrypted ballot.
45+
46+
47+
## Related work
48+
49+
### Strawman approach
50+
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.
51+
52+
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.
53+
54+
Thus we should keep some secret only to the voter himselves or the backend to prevent adversary unlock the ballot.
55+
56+
### Swiss POST evoting system
57+
Swiss POST implement their own [evoting system](https://www.evoting.ch/en) which support the verifiability of the casted ballot.
58+
59+
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.
60+
```mermaid
61+
sequenceDiagram
62+
autonumber
63+
64+
participant User
65+
participant TrustedDevice
66+
participant Backend
67+
participant Node
68+
69+
User ->>+ TrustedDevice: cast vote
70+
TrustedDevice ->>+ Backend: plain ballot
71+
Note Over Backend: Generated random voteID, use it as RNG to generate encBallotReport.
72+
Backend ->> Node: Send encBallotReport to NodeNetwork
73+
Backend ->>- TrustedDevice: encBallotReport + voteID
74+
TrustedDevice ->>- User: show encBallot Report (via QR code etc)
75+
76+
Note Over User: Use the voteID and verify the encBallotReport
77+
Note Over User: verify via Hash of report etc.
78+
79+
```
80+
81+
### Benaloh Challenge
82+
[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.
83+
84+
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.
85+
86+
```mermaid
87+
sequenceDiagram
88+
autonumber
89+
90+
participant User
91+
participant TrustedDevice
92+
participant Backend
93+
participant Node
94+
95+
User ->>+ TrustedDevice: marks ballot
96+
TrustedDevice ->>+ Backend: plain ballot
97+
Note Over Backend: Encrypted her marked ballot (using random factors from an RNG)
98+
Note Over Backend: presents a one-way hash of her encVote (via QR code) (commitment)
99+
Backend ->>- TrustedDevice: send one-way hash and provide two option (cast/challenge)
100+
TrustedDevice ->>- User: show Report (via QR code etc)
101+
Note Over User: if user decide to "cast", process is done
102+
Note Over User: if he/she choose challenge, she can scan the QR (hash of encVote) and select challenges.
103+
104+
TrustedDevice ->>+ Backend: send challenge request
105+
Backend ->>- TrustedDevice: give the marked-ballot and random factors RNG.
106+
107+
Note Over User, TrustedDevice: checks commitment by re-computing commitment using markedBallot & RNG
108+
Note Over User, TrustedDevice: if different, Backend is compromised
109+
Note Over User, TrustedDevice: if same, return to step 1, (remark ballot)
110+
Note Over User, TrustedDevice: can repeat the protocol as many as they wish until casts her ballot.
111+
```
112+
113+
The voting machine must produce the commitment before it knows wether it will be challanged or not. If the voting machine tries to cheat (change the vote), it does not know if it will be challanged or if the vote will be cast before it must commit to the ciphertext of the encrytpted vote. This means that any attempt at cheating by the voting machine will have a chance of being caught.
114+
115+
In the context of an election, the Benaloh Challange ensues that systematic cheating by voting machines will be discoverd with a very high probability. Changing a few votes has a decent chance of going undetected, but every time the voting machine cheats, it risks being caught if misjudges when a user might choose to challenge.
116+
117+
118+
## Proposed solution 1
119+
When frontend encrypt the ballot, it randomly generate an voteSecret (UUID) for the ballot and then used it as a random seed as a parameter for the Elgamal Curve. After the vote been encrypted and send to backend, User will receive a message the voteSecret. The user later can use the voteSecret during the verification process to check if its vote has been casted correctly or not.
120+
121+
```mermaid
122+
sequenceDiagram
123+
autonumber
124+
125+
participant User
126+
participant Backend
127+
participant NodeX
128+
participant NodeY
129+
130+
User ->>+ NodeX: GET election info
131+
NodeX ->>- User: Return election info.
132+
133+
User ->>+ Backend: POST /api/evoting/elections/<electionId>
134+
Note over User: data: {"Ballot": ...}
135+
Note over User: generate random voteSecret, used it as Elgamal seed
136+
Note over User: encrypt ballot via Elgamal encryption using electionPubKey
137+
Note over User, Backend: data = encrypted ballot
138+
Note over Backend: check role and sign payload.
139+
Note over Backend: add userID inside payload.
140+
Note over Backend: sign = kyber.sign.schnorr.sign(edCurve, scalar, hash);
141+
Backend ->>+ NodeX: POST /evoting/elections/
142+
143+
Note over Backend, NodeX: data: {"Payload": dataStrB64, "Signature": ""}
144+
Note over NodeX: verify and execute, then boardcast
145+
NodeX ->> NodeY: boardcase via gRPC
146+
147+
NodeX ->>- Backend: 200 OK text/plain
148+
Backend ->>- User: 200 OK text/plain + voteSecret
149+
150+
Note over User: use voteSecret as an input for verification function.
151+
User ->>+ NodeX: get encrypted ballot for that user.
152+
NodeX ->>- User: return encrypted ballot.
153+
```
154+
155+
However, this design is still not perfect because it didn't have coercion resistance property because coercers will know the voteSecret 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.
156+
157+
### frontend
158+
- Edit the submit vote function
159+
- generate a random voteSecret
160+
- can use either UUID or short UUID.
161+
- make sure to use cryptographically secure pseudorandom number generator library to generate this number
162+
- use the voteSecret as a random seed input to the encryption function.
163+
- show the voteSecret to user after the frontend send the request to the backend.
164+
- Create a page for verify the ballot
165+
- A user can select the specific election they want to verify.
166+
- The user fill the election form and last input the voteSecret.
167+
- The frontend will create a ciphertext using the voteSecret and the ballot choice.
168+
- The frontend request the encrypted vote from the node and check if the encrypted vote is same as the ciphertext.
169+
- The frontend will show the compare result to the user.
170+
171+
### Blockchain node
172+
- edit api "/evoting/forms/{formID}", add the hash of the ballot.
173+

0 commit comments

Comments
 (0)