update diss

README.md

@@ -1,8 +1,6 @@
 # Riskless
 ### Undergraduate dissertation
 
-**Paper: https://judesouthworth.xyz/Dissertation.pdf**
-
 ## Running the demo
 
 1. `pip install -r requirements.txt`

whitepaper/Dissertation.bib

@@ -254,6 +254,15 @@ doi={10.1109/SP.2014.36}}
     howpublished = {\url{https://github.com/tc39/proposal-bigint}},
 }
 
+@misc{ipfs,
+	author = {IPFS},
+	title = {IPFS Specifications},
+	year = {2023},
+	publisher = {GitHub},
+	journal = {GitHub repository},
+	howpublished = {\url{https://github.com/ipfs/specs}},
+}
+
 @misc{msgpack,
     author = {msgpack},
     title = {{MessagePack}: Spec},
@@ -425,3 +434,26 @@ doi={10.1109/SP.2014.36}}
     abstract="In this paper, we address the question of providing security proofs for signature schemes in the so-called random oracle model [1]. In particular, we establish the generality of this technique against adaptively chosen message attacks. Our main application achieves such a security proof for a slight variant of the El Gamal signature scheme [4] where committed values are hashed together with the message. This is a rather surprising result since the original El Gamal is, as RSA [11], subject to existential forgery.",
     isbn="978-3-540-68339-1"
 }
+
+@inproceedings {wasm,
+	author = {Abhinav Jangda and Bobby Powers and Emery D. Berger and Arjun Guha},
+	title = {Not So Fast: Analyzing the Performance of {WebAssembly} vs. Native Code},
+	booktitle = {2019 USENIX Annual Technical Conference (USENIX ATC 19)},
+	year = {2019},
+	isbn = {978-1-939133-03-8},
+	address = {Renton, WA},
+	pages = {107--120},
+	url = {https://www.usenix.org/conference/atc19/presentation/jangda},
+	publisher = {USENIX Association},
+	month = jul,
+}
+
+@INPROCEEDINGS{upnp,
+	author={Esnaashari, Shadi and Welch, Ian and Komisarczuk, Peter},
+	booktitle={2013 27th International Conference on Advanced Information Networking and Applications Workshops}, 
+	title={Determining Home Users' Vulnerability to Universal Plug and Play (UPnP) Attacks}, 
+	year={2013},
+	volume={},
+	number={},
+	pages={725-729},
+	doi={10.1109/WAINA.2013.225}}

whitepaper/Dissertation.tex

@@ -24,6 +24,7 @@
 \usepackage{tabularx}
 \usepackage{booktabs}
 \usepackage{ragged2e}
+\usepackage{hyperref}
 \usepackage[alph]{parnotes}
 
 \DeclareMathOperator{\lcm}{lcm}
@@ -55,15 +56,13 @@
 
 \maketitle
 
-%\chapter*{}
+\chapter*{}
-%
+
-%\begin{center}
+\section{Acknowledgements}
-%	With thanks to Dr. Jim Laird and Dr. Guy McCusker.
+
-%
+\begin{center}
-%    "Never create anything, it will be misinterpreted, it will chain you and follow you for the rest of your life." - Hunter S. Thompson
+	With thanks to Dr. Jim Laird and Dr. Guy McCusker.
-%\end{center}
+\end{center}
-%
-%\clearpage
 
 \section{Disambiguation}
 
@@ -80,13 +79,24 @@
 		$\mathbb{Z}^*_k$ & Multiplicative group of units modulo $k$ \\
 		$\gcd(a, b)$ & Greatest common divisor of $a, b$ \\
 		$\lcm(a, b)$ & Least common multiple of $a, b$ \\
-		$\phi$ & Euler's totient function \\
+		$\phi(k)$ & Euler's totient function \\
-		$\lambda$ & Carmichael's totient function \\
+		$\lambda(k)$ & Carmichael's totient function \\
 		$H(\dots)$ & Ideal cryptographic hash function \\
+		$\in_R$ & Selection at random \\
 		\bottomrule
 	\end{tabularx}
 \end{table}
 
+\vspace*{0.1\paperheight}
+\begin{center}
+	"Never create anything, it will be misinterpreted, it will chain you and follow you for the rest of your life." - Hunter S. Thompson
+	
+	\vspace*{0.05\paperheight}
+	Artefact available at \url{https://gitea.jellypro.xyz/jude/Riskless}
+\end{center}
+
+\clearpage
+
 \chapter{Outline}
 
 Risk is a strategy game developed by Albert Lamorisse in 1957. It is a highly competitive game, in which players battle for control over regions of a world map by stationing units within their territories in order to launch attacks on neighbouring territories that are not in their control.
@@ -109,11 +119,11 @@ Without patching the executables, there is no way for a user to run their own se
 
 In peer-to-peer (P2P) networks, traffic may be routed directly to other peers, or servers may be operated by third parties (sometimes called "federated networks"). This form of communication is still popular in certain games or services, for example BitTorrent is primarily a P2P service; and titles from the Counter-Strike series are federated, with a wide selection of third party hosts.
 
-The main advantage of peer-to-peer networks over centralised networks is longevity. Games such as Unreal Tournament 99 (which is federated) still have playable servers, as the servers are community-run, and so as long as people still wish to play the game, they will remain online (despite the original developers no longer making any profit from the title) \cite{eatsleeput.com_2022}.
+The main advantage of P2P networks over centralised networks is longevity. Games such as Unreal Tournament 99 (which is federated) still have playable servers, as the servers are community-run, and so as long as people still wish to play the game, they will remain online (despite the original developers no longer making any profit from the title) \cite{eatsleeput.com_2022}.
 
-However, security can often be worse in fully peer-to-peer networks than that of fully centralised networks. Peers may send malicious communications, or behave in ways that violate the general rules of the service. As there is no trusted server, there is no easy way to validate communications to prevent peers from cheating.
+However, security can often be worse in fully P2P networks than that of fully centralised networks. Peers may send malicious communications, or behave in ways that violate the general rules of the service. As there is no trusted server, there is no easy way to validate communications to prevent peers from cheating.
 
-Some peer-to-peer services try to address issues with security. In file-sharing protocols such as BitTorrent, a tracker supplies hashes of the file pieces to validate the file being downloaded \cite{cohen_2017}. However, the downside of this approach is that a trusted party (in this case the tracker) is still required. A malicious tracker could supply bad hashes, or an outdated tracker may expose peers to security vulnerabilities.
+Some P2P services try to address issues with security. In file-sharing protocols such as BitTorrent, a tracker supplies hashes of the file pieces to validate the file being downloaded \cite{cohen_2017}. However, the downside of this approach is that a trusted party (in this case the tracker) is still required. A malicious tracker could supply bad hashes, or an outdated tracker may expose peers to security vulnerabilities.
 
 \subsection{Untrusted setups}
 
@@ -153,41 +163,38 @@ Bit commitment schemes can also be implemented using one-way functions: \begin{e
 
 Protocols exist for flipping fair coins "across a telephone", which is isomorphic to selecting a random value from a set of two values \cite{blum1983coin}. This cannot be simply repeated though to generate numbers in the range of 1-6, as 6 is not a power of 2.
 
-However, a similar protocol can be used where each player commits to a single value $x \in \mathbb{Z}_6$. As the distribution of outcomes of addition in the group $\mathbb{Z}_n$ is fair, we can then sum the values of $x$ committed to by both players to deduce a final value for the roll. To decrease the amount of communications required for rolling a number of dice, a vector of values can be used.
+However, a similar protocol can be used where each player commits to a single value $x \in \mathbb{Z}_6$. As the distribution of outcomes of addition in the group $\mathbb{Z}_n$ is fair, we can then sum the values of $x$ committed to by both players to deduce a final value for the roll. This is a standard application of bit commitment, and nicely generalises Blum's original paper.
-
-This protocol relies only on the ability for one party to produce random numbers. We can consider the $\mathbb{Z}_6$-set on $\mathbb{Z}_6$: upon one party selecting $x \in \mathbb{Z}_6$, the other party's selection is from the group $x \cdot \mathbb{Z}_6 = \{ x + 0, \dots, x + 5 \} \cong \mathbb{Z}_6$. So, the potential outcomes only require one party to select randomly.
-
-If both parties were to collude and generate non-randomly, this protocol falls through. A potential way around this is to involve other players in the protocol: the same rule applies of only a single player needs to be selecting randomly to produce random outputs. Therefore, so long as there are non-colluding players, this should protect against basic collusion.
 
 \subsection{Zero-knowledge proofs}
 
-Zero-knowledge proofs form a subset of minimum disclosure proofs, and beyond that, a subset of interactive proofs. Zero-knowledge proofs are defined by three properties: \begin{itemize}
+Informally, zero-knowledge proofs can be considered to be protocols between two parties (the prover and the verifier) that operate on some given statement. The protocol holds the following three properties: \begin{itemize}
-    \item \textbf{Completeness.} If the conjecture is true, an honest verifier will be convinced of its truth by a prover.
+	\item \textbf{Completeness.} If the statement is true, an honest verifier will be convinced of its truth by a prover.
-    \item \textbf{Soundness.} If the conjecture is false, a cheating prover cannot convince an honest verifier (except with some small probability).
+	\item \textbf{Soundness.} If the statement is false, a cheating prover cannot convince an honest verifier (except with some small probability).
-    \item \textbf{Zero-knowledge.} This is the condition for a minimum disclosure proof to be considered zero-knowledge. If the conjecture is true, the verifier cannot learn any other information besides the truthfulness.
+	\item \textbf{Zero-knowledge.} If the statement is true, the verifier cannot learn any other information besides its truthfulness.
 \end{itemize}
 
-Zero-knowledge proofs are particularly applicable to the presented problem. They primarily solve two problems: \begin{itemize}
+Typically, this protocol will involve the verifier producing a set of challenges, which the prover will respond to.
-    \item The disclosure of some information without leaking other information.
-    \item The proof presented can only be trusted by the verifier, and not by other parties.
-\end{itemize}
 
-We can further formalise the general description of a zero-knowledge proof. The common formalisation of the concept of a zero-knowledge proof system for a language $L$ is
+Formally, a zero-knowledge proof system for a language $L$ is:
 \begin{itemize}
-    \item For every $x \in L$, the verifier will accept $x$ following interaction with a prover.
+	\item For every $x \in L$, the verifier will accept $x$ following interaction with a prover.
-    \item For some polynomial $p$ and any $x \notin S$, the verifier will reject $x$ with probability at least $\frac{1}{p(|x|)}$.
+	\item For some polynomial $p$ and any $x \notin S$, the verifier will reject $x$ with probability at least $\frac{1}{p(|x|)}$.
-    \item A verifier can produce a simulator $S$ such that for all $x \in L$, the outputs of $S(x)$ are indistinguishable from a transcript of the proving steps taken with the prover on $x$.
+	\item A verifier can produce a simulator $S$ such that for all $x \in L$, the outputs of $S(x)$ are indistinguishable from a transcript of the proving steps taken with the prover on $x$.
 \end{itemize}
 
 The final point describes a proof as being \textit{computationally zero-knowledge}. Some stronger conditions exist, which describe the distributions of the outputs of the simulator versus the distributions of the outputs of interaction with the prover. \begin{itemize}
-    \item \textbf{Perfect.} A simulator produced by a verifier produces outputs that are distributed identically to real transcripts.
+	\item \textbf{Statistical.} A simulator produced by a verifier gives transcripts distributed identically, except for some constant number of exceptions.
-    \item \textbf{Statistical.} A simulator produced by a verifier gives transcripts distributed identically, except for some constant number of exceptions.
+	\item \textbf{Perfect.} A simulator produced by a verifier produces outputs that are distributed identically to real transcripts.
 \end{itemize}
 
-Some proofs described are \emph{honest-verifier} zero-knowledge proofs. In these circumstances, the verifier is required to act in accordance with the protocol for the simulator distribution to behave as expected. This imposes a significant issue: a malicious verifier may intentionally produce challenges that reveal more information.
+Zero-knowledge proofs are particularly applicable to the presented problem. They primarily solve two problems: \begin{itemize}
+	\item The disclosure of some information without leaking other information.
+	\item The proof presented can only be trusted by the verifier, and not by other parties.
+\end{itemize}
 
-One solution to this is to transform a proof into a non-interactive zero-knowledge proof. The Fiat-Shamir transformation \cite{fiatshamir} converts an interactive zero-knowledge proof into a non-interactive zero-knowledge proof. In this process, the ability for a verifier to behave maliciously is lost, as the verifier no longer produces challenges themselves. This relies strongly upon the random-oracle model however \cite{randomoracle}.
+\emph{Honest-verifier} zero-knowledge is a subset of general zero-knowledge, in which the verifier is required to act in accordance with the protocol for the simulator distribution to behave as expected. This imposes a significant issue: a malicious verifier may behave as to try and attain additional information.
-As the random-oracle model is not realistically attainable, it must be approximated, typically by a cryptographic hash function. This introduces greater ability for the prover to cheat if they know a preimage in the hash function used.
+
+One solution to this is to transform a proof into a non-interactive zero-knowledge proof. The Fiat-Shamir transformation \cite{fiatshamir} converts an interactive zero-knowledge proof into a non-interactive zero-knowledge proof. In this process, the ability for a verifier to behave maliciously is lost, as the verifier no longer produces challenges themselves. This relies strongly upon the random-oracle model however \cite{randomoracle}. As the random-oracle model is not realistically attainable, it must be approximated, typically by a cryptographic hash function. This introduces greater ability for the prover to cheat if they know a preimage in the hash function used.
 
 \subsubsection{Games as graphs}
 
@@ -225,8 +232,6 @@ These are utilised to construct and verify transactions called \texttt{POUR}s. A
 
 Zerocash then uses zk-SNARKs as a means to prove that the value of the inputs into a \texttt{POUR} is the same as the value of the outputs. This prevents users from generating "debt", or from generating value without going through a minting process (also defined in the Zerocash spec).
 
-\subsubsection{Ensuring consistency of weights}
-
 A similar issue appears in the proposed system: a cheating player could update the weights on their graph to cause a region to be "in debt". Therefore, we need the protocol to ensure players prove that the sum of all edges is equal to how many units the player has in play (a well-known value).
 
 \subsubsection{Additive homomorphic cryptosystems}
@@ -274,7 +279,7 @@ An alternative general protocol is the $\Sigma$-protocol \cite{groth2004honest}.
 \end{itemize}
 This reduces the number of communications to a constant, even for varying numbers of challenges.
 
-The Fiat-Shamir heuristic \cite{fiatshamir} provides another method to reduce communication by constructing non-interactive zero-knowledge proofs using a random oracle. For ledgers, non-interactive zero-knowledge proofs are necessary, as the ledger must be resilient to a user going offline. This is not the same in our case, however non-interactive zero-knowledge proofs are still beneficial. The amount of communications can be reduced significantly, and it is easier to write code that can settle a non-interactive proof than an interactive proof.
+The Fiat-Shamir heuristic \cite{fiatshamir}, as discussed above, is another way to reduce communication by using a random oracle. For ledgers, non-interactive zero-knowledge proofs are necessary, as the ledger must be resilient to a user going offline. This is not the same in our case, however non-interactive zero-knowledge proofs are still beneficial as the amount of communications can be reduced significantly, which results in simpler network code.
 
 The downside of using the Fiat-Shamir heuristic in our implementation is that any third party can verify proofs. In some situations, we do not want this to be the case.
 
@@ -282,7 +287,7 @@ The downside of using the Fiat-Shamir heuristic in our implementation is that an
 
 The implementation provided uses WebSockets as the communication primitive. This is therefore a centralised implementation. However, no verification occurs in the server code, which instead simply "echoes" messages received to all connected clients.
 
-Despite this approach being centralised, it does emulate a fully peer-to-peer environment, and has notable benefits: \begin{itemize}
+Despite this approach being centralised, it does emulate a fully P2P environment, and has notable benefits: \begin{itemize}
     \item There is no need for hole-punching or port-forwarding.
     \item WebSockets are highly flexible in how data is structured and interpreted.
 \end{itemize}
@@ -622,19 +627,9 @@ A proof for the following homologous problem can be trivially constructed: given
 
 This is used in point (2), as one player can then convince a neighbour in zero-knowledge of the number of units within their region.
 
-\subsection{Range proof}
-
-\cite[Section~2]{bcdg1987} demonstrates a proof that an encryption of a plaintext in the interval $[0, \ell]$ lies within the interval $[-\ell, 2\ell]$, where $\ell$ is some well-known value. So, the soundness and completeness of this proof are not the same.
-
-Through selection of specific private inputs, a prover can create a proof for a plaintext $m$ in the soundness interval and not the completeness interval. In this case, the proof is also not in zero-knowledge, as the verifier can infer more specific information on the value of $m$.
-
-An alternative approach that is in zero-knowledge with acceptable soundness/completeness is to use a set membership proof for a set of all allowable values. This requires too much processing to be effective in this application however.
-
-The range proof is used in points (3), (4), and (5). In (3), this is to convince other players that the number of units is sufficient for the action. In (4), this is to show that the region is not totally depleted. In (5), this is to ensure the number of units being fortified is less than the strength of the region.
-
 \subsection{Proving reinforcement}
 
-We now need to consider point (1). One option is to prove that the sum of the committed values is 1 by using the additive homomorphic property. However, this allows a player to cheat by using negative values. To overcome this, we want a new protocol that is still in zero-knowledge, but proves additional properties of a reinforce action.
+Consider point (1). One option is to prove that the sum of the committed values is 1 by using the additive homomorphic property. However, this allows a player to cheat by using negative values. To overcome this, we want a new protocol that is still in zero-knowledge, but proves additional properties of a reinforce action.
 
 \begin{figure}[htp]
     \centering
@@ -724,9 +719,7 @@ We now need to consider point (1). One option is to prove that the sum of the co
     \caption{Valid and invalid reinforce messages. Notably, the final invalid message would not be caught by the additive homomorphic check.}
 \end{figure}
 
-One consideration is to use a range proof. The full proof would then be the combination of a proof that the sum of all ciphertexts is 1, and the range of each ciphertext is as tight as possible. This requires a large amount of rounds though, and still has the issue of soundness/completeness.
+To prove this, the prover will demonstrate that a bijection exists between the elements in the reinforcement set and a "good" set.
-
-Instead of proving a value is within a range, the prover will demonstrate that a bijection exists between the elements in the reinforcement set and a known "good" set.
 
 \begin{protocol}\label{protocol1}
 	The prover transmits the set \begin{align*}
@@ -738,7 +731,7 @@ Instead of proving a value is within a range, the prover will demonstrate that a
 	\begin{enumerate}
 		\item Prover transmits $\{ (\psi(R_i), E(n_i, r_i^*)) \mid 0 < i \leq N \}$ where $\psi$ is a random bijection on the regions.
 
-		\item Verifier chooses a random $c \in \{0, 1\}$. \begin{enumerate}
+		\item Verifier picks $c \in_R \{0, 1\}$. \begin{enumerate}
 			\item If $c = 0$, the verifier requests the definition of $\psi$. They then compute the product of the $E(x, r_i) \cdot E(x, r_i^*)$ and request proofs that each of these is zero.
 
 			\item If $c = 1$, the verifier requests a proof that each $E(n_i, r_i^*)$ is as claimed.
@@ -773,13 +766,45 @@ Additionally, this protocol is perfectly simulatable.
 	This gives $T^*$ such that $T^*(S) = T(P, V, S)$, and the output distributions are identical. Hence, this proof is perfectly simulatable under random oracle model.
 \end{proof}
 
-This is as close to perfect zero-knowledge as we can get due to the honest-verifier condition of the zero proof.
+In practice, as we are using Jurik's form of Paillier, this is computational zero-knowledge. This is because Jurik's form relies upon the computational indistinguishability of the sequence generated by powers of $h$ to random powers.
 
-In practice, as we are using Jurik's form of Paillier, the best we can hope for is computational zero-knowledge. This is because Jurik's form relies upon the computational indistinguishability of the sequence generated by powers of $h$ to random powers.
+\subsection{Range proof}
+
+The BCDG proof proves that an encryption of a plaintext in the interval $[0, \ell]$ lies within the interval $[-\ell, 2\ell]$, where $\ell$ is some well-known value \cite[Section~2]{bcdg1987}.
+
+The distinction between the soundness and completeness intervals is important, as through selection of specific private inputs, a prover can create a proof for a plaintext $m$ in the soundness interval and not the completeness interval. In this case, the proof is also not in zero-knowledge, as the verifier may be able to infer a stronger upper or lower bound on $m$.
+
+An alternative approach involves proving an upper bound on $|m|$ by constructing commitments to the bits of $m$, and using homomorphic properties \cite[Section~1.2.1]{Boudot2000EfficientPT}. Given valid encryptions of a sequence of bits, we can reconstruct the number: let $b_1, \dots, b_{|m|}$ be the bits of $m$ ($b_1$ being the LSB), and $c_i = E(b_i) = g^{b_i} r^n \mod n^2$. Then, we can construct an encryption of $m$ as \begin{align*}
+	E(m) = (c_1)^{(2^0)} \cdot (c_2)^{(2^1)} \cdot (c_3)^{(2^2)} \cdot \ldots \cdot (c_{|m|})^{(2^{|m| - 1})}.
+\end{align*}
+
+Validating $E(m)$ is done with the proof of zero. Then it remains to prove that each $c_i$ enciphers either a 0 or a 1. This can be done in a similar way to \hyperref[protocol1]{Protocol~\ref*{protocol1}}.
+
+\begin{protocol}\label{protocol4}
+	The prover transmits $c = E(m)$, and encryptions of the bits $c_1, \dots, c_{|m|}$, except using $-1$ in place of $1$.
+	
+	\begin{enumerate}
+		\item The verifier computes \begin{align*}
+			c \cdot \prod_i^{|m|} (c_i)^{(2^{i-1})}
+		\end{align*} and requests a proof of zero.
+	
+		\item Perform $t$ times for each $i$: \begin{enumerate}
+			\item Prover transmits $S = \{ E(0), E(1) \}$.
+			
+			\item Verifier picks $a \in_R \{ 0, 1 \}$. \begin{enumerate}
+				\item If $a = 0$, the verifier requests a proof that $S = \{ 0, 1 \}$.
+				
+				\item If $a = 1$, the verifier requests a proof that $c_i \cdot s_i$ is zero for one of the $s_i \in S$.
+			\end{enumerate}
+		\end{enumerate}
+	\end{enumerate}
+\end{protocol}
+
+Range proof is used in points (3), (4), and (5). In (3), this is to convince other players that the number of units is sufficient for the action. In (4), this is to show that the region is not totally depleted. In (5), this is to ensure the number of units being fortified is less than the strength of the region. All of these are performed using \hyperref[protocol4]{Protocol~\ref*{protocol4}} and by using the additive homomorphic property to subtract the lower range from $m$ first.
 
 \subsection{Proving fortifications}
 
-Point (5) still remains, as the range proof alone only works to prevent negative values from appearing in a fortify action. Fortify actions need to be of form $\{ k, -k, 0, \dots, 0 \}$) and the regions corresponding to $k, -k$ amounts must be adjacent.
+Point (5) still remains, as the range proof alone only works to prevent negative values from appearing in the resolution of a fortify action. Fortify actions need to be of form $\{ k, -k, 0, \dots, 0 \}$) and the regions corresponding to $k, -k$ amounts must be adjacent.
 
 \begin{figure}[htp]
 \centering
@@ -811,7 +836,7 @@ Point (5) still remains, as the range proof alone only works to prevent negative
 \caption{Example state change from fortify action.}
 \end{figure}
 
-\begin{figure}[H]
+\begin{figure}[htp]
     \centering
     \begin{tikzpicture}
         \tikzstyle{style}=[circle,draw=black,minimum size=10mm,fill=white]
@@ -886,7 +911,7 @@ We combine some ideas from the graph isomorphism proofs with ideas from before t
         \item Verifier chooses a random $c \in \{0, 1\}$. \begin{enumerate}
             \item If $c = 0$, the verifier requests the definition of $\psi$ and each salt. They check that the resulting graph is isomorphic to the original graph. They then compute $E(n_i, r_i) \cdot E(-n_i, r_i^*)$ for each $i$ and request a proof that each is zero. Finally, they compute each edge hash and check that there are precisely the correct number of hashes.
 
-            \item If $c = 1$, the verifier requests proofs that $|S| - 2$ are zero and that the remaining pair add to zero. They then request the salt used to produce the hash along the edge joining the two non-zero elements, and test that this hash is correct.
+            \item If $c = 1$, the verifier requests proofs that $|S| - 2$ elements are zero and that the remaining pair add to zero. They then request the salt used to produce the hash along the edge joining the two non-zero elements, and test that this hash is correct.
         \end{enumerate}
     \end{enumerate}
 \end{protocol}
@@ -982,7 +1007,7 @@ I tested this on top of the alternative Paillier scheme from above. This resulte
 
 The other proofs do not translate so trivially to this structure however. In fact, in some contexts the proofs required may be considerably more complicated, becoming round-based proofs which may be slower and use more Paillier encryptions to achieve the same effect.
 
-\textbf{Optimising language.} An optimising language may be able to reduce the time taken to encrypt. On the browser, this could involve using WASM as a way to execute compiled code within the browser, although WASM does not always outperform JavaScript.
+\textbf{Optimising language.} An optimising language may be able to reduce the time taken to encrypt. On the browser, this could involve using WASM as a way to execute compiled code within the browser, although WASM does not always outperform JavaScript \cite{wasm}.
 
 \subsection{Complexity results}
 
@@ -1008,20 +1033,19 @@ All measurements were taken on Brave 1.50.114 (Chromium 112.0.5615.49) 64-bit, u
 \begin{table}
 	\fontsize{10pt}{10pt}\selectfont
 	\caption{Time\parnote{$|n| = 4096$ uses a less-optimised encryption method, as the browser frequently timed out attempting to pre-compute for the more-optimised version.} to process proofs}
-	\begin{tabularx}{\hsize}{c *8{>{\Centering}X}}
+	\begin{tabularx}{\hsize}{c *6{>{\Centering}X}}
 		\toprule
 		\multirow{2}{*}{Modulus size} &
 		\multicolumn{2}{c}{Proof-of-zero non-interactive} &
 		\multicolumn{2}{c}{\hyperref[protocol1]{Protocol~\ref*{protocol1}} with $t = 24$} &
-		\multicolumn{2}{c}{\hyperref[protocol1]{Protocol~\ref*{protocol1}} with $t = 48$} &
 		\multicolumn{2}{c}{BCDG Range with $t = 24$}
 		\tabularnewline
-		\cmidrule(l){2-3}\cmidrule(l){4-5}\cmidrule(l){6-7}\cmidrule(l){8-9}
+		\cmidrule(l){2-3}\cmidrule(l){4-5}\cmidrule(l){6-7}
-		& Prover & Verifier & Prover & Verifier & Prover & Verifier & Prover & Verifier \\
+		& Prover & Verifier & Prover & Verifier & Prover & Verifier \\
 		\midrule
-		$|n| = 1024$ & 10ms & 18ms & 1,420ms & 2,140ms & 2,900ms & 4,270ms & 443ms & 655ms \\
+		$|n| = 1024$ & 10ms & 18ms & 1,420ms & 2,140ms & 443ms & 655ms \\
-		$|n| = 2048$ & 44ms & 68ms & 6,390ms & 8,140ms & 13,200ms & 16,200ms & 1,980ms & 2,400ms \\
+		$|n| = 2048$ & 44ms & 68ms & 6,390ms & 8,140ms & 1,980ms & 2,400ms \\
-		$|n| = 4096$ & 225ms & 292ms & 41,500ms & 34,400ms & 83,200ms & 68,400ms & 14,300ms & 11,400ms \\
+		$|n| = 4096$ & 225ms & 292ms & 41,500ms & 34,400ms & 14,300ms & 11,400ms \\
 		\bottomrule
 	\end{tabularx}
 	\parnotes
@@ -1031,16 +1055,16 @@ All measurements were taken on Brave 1.50.114 (Chromium 112.0.5615.49) 64-bit, u
 	\fontsize{10pt}{10pt}\selectfont
 	\caption{Byte size\parnote{1 UTF-16 character, as used by ECMAScript \cite[Section~6.1.4]{ecma2024262}, is 2 or more bytes.} of encoded proofs}
     \label{table3}
-	\begin{tabularx}{\hsize}{c *8{>{\Centering}X}}
+	\begin{tabularx}{\hsize}{c *6{>{\Centering}X}}
 		\toprule
-		\multirow{2}{*}{Modulus size} & \multicolumn{2}{c}{Proof-of-zero non-interactive} & \multicolumn{2}{c}{\hyperref[protocol1]{Protocol~\ref*{protocol1}} with $t = 24$} & \multicolumn{2}{c}{\hyperref[protocol1]{Protocol~\ref*{protocol1}} with $t = 48$} & \multicolumn{2}{c}{BCDG Range with $t = 24$}
+		\multirow{2}{*}{Modulus size} & \multicolumn{2}{c}{Proof-of-zero non-interactive} & \multicolumn{2}{c}{\hyperref[protocol1]{Protocol~\ref*{protocol1}} with $t = 24$} & \multicolumn{2}{c}{BCDG Range with $t = 24$}
 		\tabularnewline
-		\cmidrule(l){2-3}\cmidrule(l){4-5}\cmidrule(l){6-7}\cmidrule(l){8-9}
+		\cmidrule(l){2-3}\cmidrule(l){4-5}\cmidrule(l){6-7}
-		& JSON & with LZ-String & JSON & with LZ-String & JSON & with LZ-String & JSON & with LZ-String \\
+		& JSON & with LZ-String & JSON & with LZ-String & JSON & with LZ-String \\
 		\midrule
-		$|n| = 1024$ & 1,617B & 576B & 338,902B & 95,738B & 673,031B & 186,857B & 123,354B & 34,857B \\
+		$|n| = 1024$ & 1,617B & 576B & 338,902B & 95,738B & 123,354B & 34,857B \\
-		$|n| = 2048$ & 3,153B & 1,050B & 662,233B & 187,333B & 1,315,463B & 365,086B & 252,230B & 70,868B \\
+		$|n| = 2048$ & 3,153B & 1,050B & 662,233B & 187,333B & 252,230B & 70,868B \\
-		$|n| = 4096$ & 6,226B & 1,999B & 1,315,027B & 368,646B & 2,609,131B & 721,891B & 484,117B & 135,990B \\
+		$|n| = 4096$ & 6,226B & 1,999B & 1,315,027B & 368,646B & 484,117B & 135,990B \\
 		\bottomrule
 	\end{tabularx}
 	\parnotes
@@ -1048,53 +1072,61 @@ All measurements were taken on Brave 1.50.114 (Chromium 112.0.5615.49) 64-bit, u
 
 \end{landscape}
 
-\chapter{Wider application}
+\chapter{Conclusions}
 
-Peer-to-peer software solutions have many benefits to end users: mainly being greater user freedom. I believe that the content presented here shows clear ways to extend peer-to-peer infrastructure, and reduce dependence on centralised services.
+\section{Contributions}
+
+This project has contributed an implementation of an optimised form of Paillier that is compatible with modern web browsers. It is evident that, considering current hardware, Paillier in Jurik's form is a viable cryptosystem. 
+
+The Paillier implementation provides means for Schnorr-style proofs of knowledge and also multi-round proofs of knowledge, which serialise to JSON. These are made non-interactive by applying the SHAKE cryptographic hash suite to reduce program complexity and communication cost.
+
+Multi-round proofs combining set membership and graph isomorphism are among the implementations, and have strong zero-knowledge properties once used with the Fiat-Shamir transform.
+
+\section{Wider application}
+
+P2P software solutions have many benefits to end users: mainly being greater user freedom. I believe that the content presented here shows clear ways to extend P2P infrastructure, and reduce dependence on centralised services.
 
 I propose some ideas which could build off the content here.
 
-\section{Larger scale P2P games}
+\subsection{Larger scale games}
 
-Many other games exist that the ideas presented could be applied to. Games of larger scale with a similar structure, such as Unciv, could benefit from peer-to-peer networking implemented in a similar manner. In particular, \hyperref[protocol1]{Protocol~\ref*{protocol2}} would form an intrinsic part of such games.
+Many other games exist that the ideas presented could be applied to. Games of larger scale with a similar structure, such as Unciv, could benefit from P2P networking implemented in a similar manner. In particular, \hyperref[protocol1]{Protocol~\ref*{protocol2}} would form an intrinsic part of such games.
 
-The downsides of this are that the complexity of P2P networking is far greater than a standard centralised model. This would be a considerable burden on the developers, and could hurt the performance of such a game. The time taken to process and verify proofs also makes this inapplicable to games that are real-time.
+The downsides of this are that the complexity of P2P networking is far greater than in a centralised model. This would be a considerable burden on the developers, and could hurt the performance of such a game. Additionally, some modern routers no longer support NAT hole-punching or UPnP due to security concerns \cite{upnp}, which makes accessing P2P services more difficult for end users.
 
-\section{Decentralised social media}
+\subsection{Decentralised social media}
 
 The schemes presented here could be applies to the concept of a decentralised social media platform. Such a platform may use zero-knowledge proofs as a way to allow for "private" profiles: the content of a profile may stay encrypted, but zero-knowledge proofs could be used as a way to allow certain users to view private content in a manner that allows for repudiation, and disallows one user from sharing private content to unauthorised users.
 
-To store data, IPFS could be used. IPFS is a P2P data storage protocol. This poses an advantage that users can store their own data, if they have a large amount, but other users can mirror data to protect against outages or users going offline. The amount of effective storage would also grow as more users join the network.
+To store data, IPFS could be used. IPFS is a P2P data storage protocol \cite{ipfs}. This poses an advantage that users can store their own data, but other users can mirror data to protect against outages or users going offline. The amount of effective storage would also grow as more users join the network.
 
-\section{Handling of confidential data}
+Decentralised platforms promote user privacy, as users can control their own data. Additionally, decentralised platforms promote standardisation of common operations such as instant messaging. This can include end-to-end encryption, and so confidentiality is then a choice of the user rather than the platform, and the consequences of backdoors or legislation targetting platforms is reduced.
 
-The ability to prove the contents of a dataset to a second party without guaranteeing authenticity to a third party is another potential application of the protocol presented. Handling of confidential data is a critical concern for pharmaceutical companies, where a data leak imposes serious legal and competitive consequences for the company. A second party does however need some guarantee that the data received is correct. Proofs are one way of achieving this, although other techniques such as keyed hashing may be more effective.
+Some P2P messaging standards already coexist that could be used here, for example Matrix and XMPP.
+
+\subsection{Handling of confidential data}
+
+The ability to prove the contents of a dataset to a second party without guaranteeing authenticity to a third party is another potential application of the protocol presented. Handling of confidential data is a critical concern for pharmaceutical companies, where a data leak imposes serious legal and competitive consequences for the company. To allow a second party to process data, some guarantee of the correctness of the data is required. Proofs are one way of achieving this, although other techniques such as keyed hashing may be more effective.
 
 Another consideration in this domain is the use of homomorphic encryption schemes to allow a third party to process data without actually viewing the data. This protects the data from viewing by the third party, and the processing methods from viewing by the first party. For example, common statistical functions such as regression can be performed on data that is encrypted under fully homomorphic encryption schemes.
 
-\chapter{Limitations}
+\section{Limitations}
 
-Finally, I present a summary of general limitations that I encountered.
+\subsection{JavaScript}
-
-\section{JavaScript}
 
 JavaScript was the incorrect choice of language for this project. Whilst the event-based methodology was useful, I believe overall that JavaScript made development much more difficult.
 
 JavaScript is a slow language. Prime generation takes a considerable amount of time, and this extends to encryption and decryption being slower than in an implementation in an optimising compiled language. This was seen in the results shown before.
 
-JavaScript's type system makes debugging difficult. It is somewhat obvious that this problem is far worse in systems with more interacting parts. TypeScript may have been a suitable alternative, but most likely the easiest solution was to avoid both and go with a language that was designed with stronger typing in mind from the outset (even Python would likely have been easier, as there is at least no issue of \texttt{undefined}ness, and the language was designed with objects in mind from the start).
+JavaScript's type system makes debugging difficult. It is somewhat obvious that this problem is far worse in systems with more interacting parts. TypeScript may have been a suitable alternative, but most likely the easiest solution was to avoid both and go with a language that was designed with stronger typing in mind from the outset.
 
 JavaScript is a re-entrant language: this means that the interpreter does not expose threads or parallelism to the developer, but it may still use threads under-the-hood and switch contexts to handle new events. This introduces the possibility of race conditions despite no explicit threading being used. The re-entrant nature is however beneficial to a degree, as it means that long-running code won't cause the WebSocket to close or block other communications from being processed.
 
-\section{General programming}
+Using a language that can interact with the operating system would have further advantages, as key generation can be performed by standard tools such as OpenSSL and stored in the system keychain, and features like SIMD could be utilised for parallelism.
 
-Peer-to-peer programming requires a lot more care than client-server programming. This makes development far slower and far more bug-prone. As a simple example, consider the action of taking a turn in Risk. In the peer-to-peer implementation presented, each separate peer must keep track of how far into a turn a player is, check if a certain action would end their turn (or if its invalid), contribute in verifying proofs, and contribute in generating randomness for dice rolls. In a client-server implementation, the server would be able to handle a turn by itself, and could then propagate the results to the other clients in a single predictable request.
+\subsection{Resources}
 
-The use of big integers leads to peculiar issues relating to signedness. Taking modulo $n$ of a negative number tends to return a negative number, rather than a number within the range $[0, n]$. This leads to inconsistencies when calculating the GCD or finding Bezout coefficients. In particular, this became an issue when trying to validate proofs of zero, as the GCD returned $-1$ rather than $1$ in some cases. Resolving this simply required changing the update and encrypt functions to add the modulus until the representation of the ciphertext was signed correctly. Using a non-numerical type (such as a byte array) may resolve this issue in general.
+The P2P implementation requires more processing power and more bandwidth on each peer than a client-server implementation would. This is the main limitation of the P2P implementation. The program ran in a reasonable time, using a reasonable amount of resources on the computers I had access to, but these are not representative of the majority of people. Using greater processing power increases power consumption, which is undesirable. In a client-server implementation, the power consumption should be lower than the P2P implementation presented as no processing time is spent validating proofs or using the Paillier cryptosystem, which is less efficient than the hybrid cryptosystems used in standard online communication.
-
-\section{Resources}
-
-The peer-to-peer implementation requires more processing power and more bandwidth on each peer than a client-server implementation would. This is the main limitation of the peer-to-peer implementation. The program ran in a reasonable time, using a reasonable amount of resources on the computers I had access to, but these are not representative of the majority of people. Using greater processing power increases power consumption, which is undesirable. In a client-server implementation, the power consumption should be lower than the peer-to-peer implementation presented as no processing time is spent validating proofs or using the Paillier cryptosystem, which is less efficient than the hybrid cryptosystems used in standard online communication.
 
 \bibliography{Dissertation}