jude/Riskless
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Update diss to match

Browse Source
This commit is contained in:
jude 2023-04-10 11:22:51 +01:00
parent 0991c6bff9
commit 8c5b6dbac9
2 changed files with 5 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

BIN
whitepaper/Dissertation.pdf
View File

Binary file not shown.

8
whitepaper/Dissertation.tex
View File

@ -410,12 +410,14 @@ A proof for the following homologous problem can be trivially constructed: given
\subsection{Implementation details} \subsection{Implementation details}
Proofs of zero use messages labelled as \texttt{"PROOF"} to resolve, and resolve between two parties. The proof is initialised by the prover as part of the game protocol, who sends an initial message containing the fields \texttt{conjecture: int} and \texttt{a: str} (where \texttt{a} is the serialisation of a \texttt{BigInt} representing \texttt{a} and \texttt{conjecture} is the proposed plaintext). Proofs of zero use messages labelled as \texttt{"PROOF"} to resolve, and resolve between two parties. The proof is initiated by the verifier as part of the game protocol, who sends a request containing the region to prove. Initiating proofs on the verifier side has benefits to synchronisation, and helps to reduce race conditions, as the proof is only requested after the verifier has updated their state.
The prover then registers a new event listener to respond to the verifier's challenge in a non-blocking way when received. The prover responds with the fields \texttt{conjecture: int} and \texttt{a: str} (where \texttt{a} is the serialisation of a \texttt{BigInt} representing \texttt{a} and \texttt{conjecture} is the proposed plaintext).
The prover then waits on an event listener to respond to the verifier's challenge in a non-blocking way when received.
The verifier receives the message above, and responds with a random challenge selected by generating a cryptographically secure pseudorandom number of 2048 bits, and then dropping the LSB. Using 2047 bits guarantees that the challenge is smaller than $p$ or $q$, as is suggested in the original paper. %todo why? The verifier receives the message above, and responds with a random challenge selected by generating a cryptographically secure pseudorandom number of 2048 bits, and then dropping the LSB. Using 2047 bits guarantees that the challenge is smaller than $p$ or $q$, as is suggested in the original paper. %todo why?
The verifier then registers a new event listener to receive the prover's proof. The verifier then waits on an event listener to receive the prover's proof.
Verifying the proof is a simple application of extended Euclidean algorithm to check coprimality, and a modular exponentiation and reduction to check the final equivalence. The ciphertext on the verifier's instance is then tagged with the proven plaintext (should the proof succeed). This tag is removed in the case that the ciphertext is updated. Verifying the proof is a simple application of extended Euclidean algorithm to check coprimality, and a modular exponentiation and reduction to check the final equivalence. The ciphertext on the verifier's instance is then tagged with the proven plaintext (should the proof succeed). This tag is removed in the case that the ciphertext is updated.