Skip to content

Commit 1d4299e

Browse files
chenchanglewchenchanglew
committed
update docs
1 parent da1cff9 commit 1d4299e

File tree

1 file changed

+65
-53
lines changed

1 file changed

+65
-53
lines changed

‎docs/verifiability_doc.md

+65-53
Original file line numberDiff line numberDiff line change
@@ -33,7 +33,7 @@ The current d-voting (version num) didn't have this design yet. The current encr
3333
Backend ->>- User: 200 OK text/plain
3434
```
3535

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.
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.
3737

3838
In this document, we aim to design an implementation to achieve verifiability of the voters' encrypted vote without leaking ballot information to others.
3939

@@ -78,45 +78,14 @@ sequenceDiagram
7878
7979
```
8080

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-
```
11281

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.
82+
## Proposed solution
83+
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.
11484

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.
85+
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.
11686

87+
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.
11788

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.
12089

12190
```mermaid
12291
sequenceDiagram
@@ -132,8 +101,8 @@ sequenceDiagram
132101
133102
User ->>+ Backend: POST /api/evoting/elections/<electionId>
134103
Note over User: data: {"Ballot": ...}
135-
Note over User: generate random voteSecret, used it as Elgamal seed
136104
Note over User: encrypt ballot via Elgamal encryption using electionPubKey
105+
Note over User: generate hash of encrypted ballot and show to user
137106
Note over User, Backend: data = encrypted ballot
138107
Note over Backend: check role and sign payload.
139108
Note over Backend: add userID inside payload.
@@ -147,27 +116,70 @@ sequenceDiagram
147116
NodeX ->>- Backend: 200 OK text/plain
148117
Backend ->>- User: 200 OK text/plain + voteSecret
149118
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.
119+
User ->>+ NodeX: get form details
120+
NodeX ->>- User: return form details and hash of encrypted vote.
121+
Note over User: check the hash of the vote is the same or not.
153122
```
154123

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.
124+
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.
156125

157126
### frontend
158127
- 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.
128+
- hash the encrypted ballot and show to the user.
129+
- Edit form details page to show the hash of ballot.
130+
- A user can select an election to see the details.
131+
- In the detail page, it show who is the voter and the hash of their ballot.
132+
- User can check if the hash they received is the same as the hash on the details.
170133

171134
### Blockchain node
172-
- edit api "/evoting/forms/{formID}", add the hash of the ballot.
135+
- edit api "/evoting/forms/{formID}", add the hash of the ballot to the form structure.
136+
137+
138+
## Extension coercion protection
139+
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.
140+
141+
### Benaloh Challenge
142+
[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.
143+
144+
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.
145+
146+
```mermaid
147+
sequenceDiagram
148+
autonumber
149+
150+
participant User
151+
participant TrustedDevice
152+
participant Backend
153+
participant Node
154+
155+
User ->>+ TrustedDevice: marks ballot
156+
TrustedDevice ->>+ Backend: plain ballot
157+
Note Over Backend: Encrypted her marked ballot (using random factors from an RNG)
158+
Note Over Backend: presents a one-way hash of her encVote (via QR code) (commitment)
159+
Backend ->>- TrustedDevice: send one-way hash and provide two option (cast/challenge)
160+
TrustedDevice ->>- User: show Report (via QR code etc)
161+
Note Over User: if user decide to "cast", process is done
162+
Note Over User: if he/she choose challenge, she can scan the QR (hash of encVote) and select challenges.
163+
164+
TrustedDevice ->>+ Backend: send challenge request
165+
Backend ->>- TrustedDevice: give the marked-ballot and random factors RNG.
166+
167+
Note Over User, TrustedDevice: checks commitment by re-computing commitment using markedBallot & RNG
168+
Note Over User, TrustedDevice: if different, Backend is compromised
169+
Note Over User, TrustedDevice: if same, return to step 1, (remark ballot)
170+
Note Over User, TrustedDevice: can repeat the protocol as many as they wish until casts her ballot.
171+
```
172+
173+
The voting machine must produce the commitment before it knows whether it will be challenged or not. If the voting machine tries to cheat (change the vote), it does not know if it will be challenged or if the vote will be cast before it must commit to the ciphertext of the encrypted vote. This means that any attempt at cheating by the voting machine will have a chance of being caught.
174+
175+
In the context of an election, the Benaloh Challenge ensues that systematic cheating by voting machines will be discovered 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.
176+
177+
### Proposed solution
178+
179+
Just like the Benaloh challenge, a user can assume that the backend is untrusted, and they have a Benaloh challenge with the backend.
180+
181+
The user first encrypts their ballot using the election public key and then sent it to the backend. Then the backend encrypted the encrypted ballot again with a randomly generated seed and sends the hash of the enc(enc(ballot)) to the user.
182+
183+
Then the user can choose to challenge (which backend reveals the random seed) or accept (which backend executes the vote).
173184

185+
With this approach implemented, we are able to have coercion protection. However, the node will need to decrypt the ballot two times which requires changing the decryption process and increasing the execution time.

0 commit comments

Comments
 (0)