..

static/js/modules/crypto/paillier.js

@@ -288,7 +288,7 @@ export class PaillierPubKey {
 
         for (let i = 0n; i < BigInt(KEY_SIZE); i++) {
             this._h_cache.push(mod_exp(this.h, 2n ** i, this.n));
-            this._hn_cache.push(mod_exp(this.h, 2n ** i, this.n2));
+            this._hn_cache.push(mod_exp(this.hn, 2n ** i, this.n2));
         }
     }
 

whitepaper/Dissertation.tex

@@ -81,13 +81,13 @@ The main advantage of peer-to-peer networks over centralised networks is longevi
 
 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.
 
-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 the peer to security vulnerabilities.
+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.
 
 \subsection{Untrusted setups}
 
 Currently, there exists an online centralised version of the board game Risk.
 
-We aim to apply bit-commitment schemes and zero-knowledge proof protocols to an online P2P variant of Risk, to allow peers to play the game whilst preventing cheating and needing no trusted parties. The variant of interest is the "fog of war" variant, where a player cannot see the unit counts of regions besides those that they own or are neighbouring.
+I aim to apply bit-commitment schemes, zero-knowledge proofs, and homomorphic encryption to an online P2P variant of Risk, to allow peers to play the game whilst preventing cheating and needing no trusted parties. The variant of the game that is of interest is the "fog of war" variant, where a player cannot see the unit counts of regions besides those that they own or are neighbouring.
 
 \section{Literature review}
 
@@ -107,7 +107,7 @@ Bit commitment schemes provide a mechanism for one party to commit to some hidde
 
 \cite{Shamir1981} provides a protocol using bit commitment to play poker. They offer a bit commitment scheme using commutative encryption algorithms based on modular arithmetic. This scheme works by each player encrypting cards, and decrypting in a different order as to obscure the value of the actual cards until all players have decrypted.
 
-Many encryption schemes are not commutative however. One alternative is to use some well-known one-way function, such as SHA, with randomly generated salts.
+However, almost all well-documented encryption schemes are not commutative. One alternative is to use some well-known one-way function, such as SHA, with randomly generated salts.
 
 \subsubsection{Bit commitment with one-way functions}
 
@@ -119,13 +119,13 @@ Bit commitment schemes can also be implemented using one-way functions: \begin{e
     \item The second party computes $c' = H(m, r)$ and validates that $c = c'$.
 \end{enumerate}
 
-\cite{blum1983coin} provides a protocol for flipping fair coins across a telephone, which is isomorphic to selecting a random value from a set of two values. This cannot be simply repeated though to generate numbers in the range of 1-6, as 6 is not a power of 2.
+\cite{blum1983coin} provides a protocol for flipping fair coins "across a telephone", which is isomorphic to selecting a random value from a set of two values. 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.
 
 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 would protect against basic collusion.
+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}
 
@@ -136,7 +136,7 @@ Zero-knowledge proofs form a subset of minimum disclosure proofs, and beyond tha
 \end{itemize}
 
 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 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}
 
@@ -151,7 +151,10 @@ The final point describes a proof as being \textit{computationally zero-knowledg
     \item \textbf{Statistical.} A simulator produced by a verifier gives transcripts distributed identically, except for some constant number of exceptions.
 \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.
+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.
+
+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. %todo cite
+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}