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

final?

Browse Source
This commit is contained in:
jude 2023-05-01 13:00:07 +01:00
parent 9c6b251a25
commit 46f4bfd7ff
3 changed files with 101 additions and 57 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

42
whitepaper/Dissertation.bib
View File

@ -88,6 +88,19 @@ doi={10.1109/SP.2014.36}}
isbn="978-3-642-02384-2" isbn="978-3-642-02384-2"
} }
@misc{monero,
author = {Monero Research Lab},
title = {What is {Monero} ({XMR})?}
howpublished = {\url{https://www.getmonero.org/get-started/what-is-monero/}}
}
@misc{zcash,
author = {Electric Coin Company},
organization = {Electric Coin Company},
title = {{Zcash Basics -- Zcash Documentation}},
howpublished = {\url{https://zcash.readthedocs.io/en/latest/rtd_pages/basics.html}}
}
@article{10.1145/116825.116852, @article{10.1145/116825.116852,
author = {Goldreich, Oded and Micali, Silvio and Wigderson, Avi}, author = {Goldreich, Oded and Micali, Silvio and Wigderson, Avi},
title = {Proofs That Yield Nothing but Their Validity or All Languages in NP Have Zero-Knowledge Proof Systems}, title = {Proofs That Yield Nothing but Their Validity or All Languages in NP Have Zero-Knowledge Proof Systems},
@ -479,4 +492,33 @@ doi={10.1109/SP.2014.36}}
author = {Bitcoin Cash}, author = {Bitcoin Cash},
title = {{Bitcoin Cash -- Peer-to-peer Electronic Cash}}, title = {{Bitcoin Cash -- Peer-to-peer Electronic Cash}},
howpublished = {\url{https://bitcoincash.org}} howpublished = {\url{https://bitcoincash.org}}
}
@misc{epic,
author = {{Epic Games}},
title = {Epic is turning off online services for some older games},
howpublished = {https://www.epicgames.com/site/en-US/news/epic-is-turning-off-online-services-and-servers-for-some-older-games}}
@article{bitcoin08,
author = {Nakamoto, Satoshi},
year = {2008},
month = {10},
pages = {},
title = {Bitcoin: A Peer-to-Peer Electronic Cash System},
journal = {Cryptography Mailing list at https://metzdowd.com}
}
@article{bitcoindeanon,
author = {Bohannon, John},
title = {Why criminals can't hide behind {Bitcoin}},
year = {2016},
month = {03},
day = {09},
howpublished = {\url{https://www.science.org/content/article/why-criminals-cant-hide-behind-bitcoin}}
}
@misc{slsk,
author = {"Nir"},
title = {Frequently Asked Questions | Soulseek},
howpublished = {\url{http://www.soulseekqt.net/news/faq-page#t10n606}}
} }

BIN
whitepaper/Dissertation.pdf
View File

Binary file not shown.

116
whitepaper/Dissertation.tex
View File

@ -119,9 +119,9 @@ Without patching the executables, there is no way for a user to run their own se
However, centralised services have a number of major downsides. \begin{itemize} However, centralised services have a number of major downsides. \begin{itemize}
\item \textbf{User freedom.} Users often cannot audit or modify the underlying source code. Furthermore, users must follow rules enforced by the platform, which can be arbitrarily set and enforced. \item \textbf{User freedom.} Users often cannot audit or modify the underlying source code. Furthermore, users must follow rules enforced by the platform, which can be arbitrarily set and enforced.
\item \textbf{Liability.} In some jurisdictions, platforms are held legally responsible for content on their platforms. This means that platform operators may be forced to invade the privacy of their users, and consequences are felt by the platform and not the user. \item \textbf{Liability.} In some jurisdictions, platforms are held legally responsible for content on their platforms. This means that consequences of illegal activities are sometimes felt by the platform and not the criminal user, and this encourages platforms to invade the privacy of their users.
\item \textbf{Ownership.} The service is owned by the operators. If the operators wish to close the service, it is at their own discretion. \item \textbf{Ownership.} The service is owned by the operators. If the operators wish to close the service, it is at their own discretion.
\end{itemize} \end{itemize}
@ -133,23 +133,23 @@ In P2P networks, traffic may be routed directly to other peers. In federated net
P2P and federated networks address each of the disadvantages listed above. \begin{itemize} P2P and federated networks address each of the disadvantages listed above. \begin{itemize}
\item \textbf{User freedom.} The platform is run by its users. Whilst this doesn't require that the source code is available, it allows the auditing of data collected, and the network may diverge to meet the needs of different groups of users. For example, Bitcoin Cash is a fork from Bitcoin intended to address concerns over transaction fees \cite{bch}. \item \textbf{User freedom.} The platform is run by its users. Whilst this doesn't require that the source code is available, it allows the auditing of data collected, and the network may diverge to meet the needs of different groups of users. For example, Bitcoin Cash is a fork from Bitcoin intended to address concerns over transaction fees \cite{bch}.
\item \textbf{Liability.} Users are legally responsible for their own behaviours. This can result in legal consequence against users themselves rather than the platform \cite{bittorrent2008}. \item \textbf{Liability.} Users are legally responsible for their own behaviours. This results in legal consequence against criminal users, and relative immunity of the platform \cite{bittorrent2008}.
\item \textbf{Ownership.} Games such as Unreal Tournament 99 (which is now 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 officially supporting the title) \cite{eatsleeput.com_2022}. \item \textbf{Ownership.} Games such as Unreal Tournament 99 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 officially supporting the title) \cite{eatsleeput.com_2022,epic}.
\end{itemize} \end{itemize}
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. However, general privacy can often be worse in fully P2P networks than that of fully centralised networks. As there is no trusted server, there is no easy way to hide traffic of certain users or maintain, validate, and operate on private state. For example, most popular cryptocurrencies (such as Bitcoin and Ethereum) are public-ledger, meaning transactions can be publicly tracked. This is far less private than services such as banks or cash \cite{bitcoin08,bitcoindeanon}.
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. Some P2P services try to address issues with privacy. Monero and Zcash are privacy coins that use cryptographic protocols to obscure transaction amounts \cite{monero,zcash}. The P2P file-sharing protocol Soulseek keeps a user's download history private by using direct communication between the two peers \cite{slsk}. The downside of this approach is that if the first user goes offline, files will no longer be available. BitTorrent overcomes this by pooling peers with the file into a "seed pool". The disadvantage of this approach is that the users who download files is now public knowledge \cite{cohen_2017}.
\subsection{Untrusted setups} \subsection{Untrusted setups}
Currently, there exists an online centralised version of the board game Risk. Currently, there exists an online centralised version of the board game Risk.
We 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. We aim to apply bit-commitment schemes, zero-knowledge proofs, and homomorphic encryption to an online P2P variant of Risk. This will 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: this introduces private state to be operated on.
\section{Literature review} \chapter{Literature review}
Centralised systems can securely perform the generation of random values, through using a cryptographically secure random number generator on the server-side, and distributing the values to the clients. This is how dice rolls are processed in centralised online games. However, in a P2P system, another approach must be taken to simulate the randomness, to ensure all peers receive the same random value. Centralised systems can securely perform the generation of random values, through using a cryptographically secure random number generator on the server-side, and distributing the values to the clients. This is how dice rolls are processed in centralised online games. However, in a P2P system, another approach must be taken to simulate the randomness, to ensure all peers receive the same random value.
@ -159,17 +159,17 @@ For such randomness, we also want that \begin{itemize}
\end{itemize} \end{itemize}
We apply the concept of bit-commitment schemes to form these guarantees. We apply the concept of bit-commitment schemes to form these guarantees.
\subsection{Bit-commitment schemes} \section{Bit-commitment schemes}
Bit-commitment schemes provide a mechanism for one party to commit to some hidden value and reveal it later. This can be achieved through the use of commutative cryptographic algorithms and with one-way functions. Bit-commitment schemes provide a mechanism for one party to commit to some hidden value and reveal it later. This can be achieved through the use of commutative cryptographic algorithms and with one-way functions.
\subsubsection{Commutative cryptography} \subsection{Commutative cryptography}
Protocols exist that utilise bit-commitment to play poker \cite{Shamir1981}. 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. Protocols exist that utilise bit-commitment to play poker \cite{Shamir1981}. 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.
However, almost all well-documented encryption schemes are not commutative. One alternative is to use a well-known one-way function, such as SHA \cite{FIPS202}, with randomly generated salts. However, almost all well-documented encryption schemes are not commutative. One alternative is to use a well-known one-way function, such as SHA \cite{FIPS202}, with randomly generated salts.
\subsubsection{Bit-commitment with one-way functions} \subsection{Bit-commitment with one-way functions}
Bit-commitment schemes can also be implemented using one-way functions: \begin{enumerate} Bit-commitment schemes can also be implemented using one-way functions: \begin{enumerate}
\item The first party decides on the value $m$ to be committed to. \item The first party decides on the value $m$ to be committed to.
@ -183,7 +183,7 @@ Protocols exist for flipping fair coins "across a telephone", which is isomorphi
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 to form a "secret sharing" protocol. 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 to form a "secret sharing" protocol.
\subsection{Zero-knowledge proofs} \section{Zero-knowledge proofs}
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} 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 statement 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.
@ -214,7 +214,7 @@ Zero-knowledge proofs are particularly applicable to the presented problem. They
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. However, this relies strongly upon the random-oracle model \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. 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. However, this relies strongly upon the random-oracle model \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} \subsection{Games as graphs}
The board used to play Risk can be viewed as an undirected graph. Each region is a node, with edges connecting it to the adjacent regions. For convenience, we also consider the player's hand to be a node, which has all units not in play placed upon it. The board used to play Risk can be viewed as an undirected graph. Each region is a node, with edges connecting it to the adjacent regions. For convenience, we also consider the player's hand to be a node, which has all units not in play placed upon it.
@ -234,13 +234,13 @@ The main game protocol can be considered as the following graph mutations for a
The goal is to identify ways to secure this protocol by obscuring the edges and weights, whilst preventing the ability for the player to cheat. The goal is to identify ways to secure this protocol by obscuring the edges and weights, whilst preventing the ability for the player to cheat.
\subsubsection{Graphs \& zero-knowledge proofs} \subsection{Graphs \& zero-knowledge proofs}
A typical example for zero-knowledge proofs is graph isomorphism \cite{10.1145/116825.116852}. A typical example for zero-knowledge proofs is graph isomorphism \cite{10.1145/116825.116852}.
Identifying Risk as a graph therefore enables us to construct isomorphisms as part of the proof protocol. For example, when a player wishes to commit to a movement, it is important to prove that the initial node and the new node are adjacent. This can be proven by communicating isomorphic graphs, and constructing challenges based on the edges of the original graph. Identifying Risk as a graph therefore enables us to construct isomorphisms as part of the proof protocol. For example, when a player wishes to commit to a movement, it is important to prove that the initial node and the new node are adjacent. This can be proven by communicating isomorphic graphs, and constructing challenges based on the edges of the original graph.
\subsubsection{Cheating with negative values} \subsection{Cheating with negative values}
Zerocash is a ledger system that uses zero-knowledge proofs to ensure consistency and prevent cheating. Ledgers are the main existing use case of zero-knowledge proofs, and there are some limited similarities between ledgers and Risk in how they need to obscure values of tokens within the system. Zerocash is a ledger system that uses zero-knowledge proofs to ensure consistency and prevent cheating. Ledgers are the main existing use case of zero-knowledge proofs, and there are some limited similarities between ledgers and Risk in how they need to obscure values of tokens within the system.
@ -262,7 +262,7 @@ Bulletproofs have advantages in size and "batch verification", where a verifier
In general, this approach uses a decomposition of the plaintext message $m$ into its bits. This allows a verifying party to reconstruct an encryption of $m$, and check the bit length, without discovering $m$ \cite[Section~1.2.1]{Boudot2000EfficientPT}. In general, this approach uses a decomposition of the plaintext message $m$ into its bits. This allows a verifying party to reconstruct an encryption of $m$, and check the bit length, without discovering $m$ \cite[Section~1.2.1]{Boudot2000EfficientPT}.
\subsubsection{Additive homomorphic cryptosystems} \section{Additive homomorphic cryptosystems}
Some cryptosystems admit an additive homomorphic property: that is, given the public key and two encrypted values $\sigma_1 = E(m_1), \sigma_2 = E(m_2)$, the value $\sigma_1 + \sigma_2 = E(m_1 + m_2)$ is the ciphertext of the underlying operation. Some cryptosystems admit an additive homomorphic property: that is, given the public key and two encrypted values $\sigma_1 = E(m_1), \sigma_2 = E(m_2)$, the value $\sigma_1 + \sigma_2 = E(m_1 + m_2)$ is the ciphertext of the underlying operation.
@ -290,13 +290,13 @@ Exponentials of the fixed base $h_n$ can then be pre-computed to speed up expone
Jurik states that the optimised form can lead to a theoretic four times speedup over Paillier's original form. Jurik states that the optimised form can lead to a theoretic four times speedup over Paillier's original form.
\subsubsection{Zero-knowledge proofs in Paillier cryptosystem} \subsection{Zero-knowledge proofs in Paillier cryptosystem}
There exist honest-verifier zero-knowledge proofs for proving a given value is 0 \cite[Section~5.2]{damgard2003}. Hence, proving a summation $a + b = v$ can be performed by proving $v - a - b = 0$, which is possible by the additive homomorphic property. There exist honest-verifier zero-knowledge proofs for proving a given value is 0 \cite[Section~5.2]{damgard2003}. Hence, proving a summation $a + b = v$ can be performed by proving $v - a - b = 0$, which is possible by the additive homomorphic property.
Therefore, using Paillier's scheme to obscure edge weights should enable verification of the edge values without revealing their actual values. Therefore, using Paillier's scheme to obscure edge weights should enable verification of the edge values without revealing their actual values.
\subsubsection{Reducing communication} \subsection{Reducing communication}
In the presented algorithms, interaction is performed fairly constantly, leading to a large number of communications. This will slow the system considerably, and make proofs longer to perform due to network latency. In the presented algorithms, interaction is performed fairly constantly, leading to a large number of communications. This will slow the system considerably, and make proofs longer to perform due to network latency.
@ -419,33 +419,33 @@ The game is broken down into three main stages, each of which handles events in
\node[draw=black!50,fill=white,rotate=270,rectangle,very thick,rounded corners=0.1mm,anchor=north] (Update2) at (0.5\paperwidth + 60pt, -158pt) {Update game stage}; \node[draw=black!50,fill=white,rotate=270,rectangle,very thick,rounded corners=0.1mm,anchor=north] (Update2) at (0.5\paperwidth + 60pt, -158pt) {Update game stage};
\draw[very thick,->,dashed] (End1)-- node[below] {All reinf. placed} ++(Update2); \draw[very thick,->,dashed] (End1)-- node[below] {All reinf. placed} ++(Update2);
% Player act handling 2 % Player act handling 2
\node[draw=blue!50,rectangle,very thick,rounded corners=0.1mm,anchor=north] (Act2) at (0.5\paperwidth+112pt, 0.5\textheight-4pt) {Current player acts}; \node[draw=blue!50,rectangle,very thick,rounded corners=0.1mm,anchor=north] (Act2) at (0.5\paperwidth+112pt, 0.5\textheight-4pt) {Current player acts};
\node[draw=black!50,rectangle,very thick,rounded corners=0.1mm,anchor=north] (Reinf2) at (0.5\paperwidth+280pt, 140pt) {Reinforce regions}; \node[draw=black!50,rectangle,very thick,rounded corners=0.1mm,anchor=north] (Reinf2) at (0.5\paperwidth+280pt, 140pt) {Reinforce regions};
\node[draw=black!50,rectangle,very thick,rounded corners=0.1mm,anchor=north] (Attack1) at (0.5\paperwidth+210pt, 70pt) {Attack region}; \node[draw=black!50,rectangle,very thick,rounded corners=0.1mm,anchor=north] (Attack1) at (0.5\paperwidth+210pt, 70pt) {Attack region};
\node[draw=green!50,rectangle,very thick,rounded corners=0.1mm,anchor=north] (Attack2) at (0.5\paperwidth+210pt, 20pt) {Send defence}; \node[draw=green!50,rectangle,very thick,rounded corners=0.1mm,anchor=north] (Attack2) at (0.5\paperwidth+210pt, 20pt) {Send defence};
\node[draw=blue!50,rectangle,very thick,rounded corners=0.1mm,anchor=north] (Attack3) at (0.5\paperwidth+340pt, 20pt) {Target defends}; \node[draw=blue!50,rectangle,very thick,rounded corners=0.1mm,anchor=north] (Attack3) at (0.5\paperwidth+340pt, 20pt) {Target defends};
\node[draw=green!50,rectangle,very thick,rounded corners=0.1mm,anchor=north] (Attack4) at (0.5\paperwidth+210pt, -30pt) {Resolve dice roll}; \node[draw=green!50,rectangle,very thick,rounded corners=0.1mm,anchor=north] (Attack4) at (0.5\paperwidth+210pt, -30pt) {Resolve dice roll};
\draw[very thick,->,dashed] (Attack1) -- node[right] {Target region owned by us} ++ (Attack2); \draw[very thick,->,dashed] (Attack1) -- node[right] {Target region owned by us} ++ (Attack2);
\draw[very thick,->] (Attack2) -- (Attack4); \draw[very thick,->] (Attack2) -- (Attack4);
\draw[very thick,->] (Attack3) -- (0.5\paperwidth+340pt, -15pt) -- (0.5\paperwidth+210pt, -15pt) -- (Attack4); \draw[very thick,->] (Attack3) -- (0.5\paperwidth+340pt, -15pt) -- (0.5\paperwidth+210pt, -15pt) -- (Attack4);
\node[draw=black!50,rectangle,very thick,rounded corners=0.1mm,anchor=north] (Fortify) at (0.5\paperwidth+210pt, -90pt) {Fortify region}; \node[draw=black!50,rectangle,very thick,rounded corners=0.1mm,anchor=north] (Fortify) at (0.5\paperwidth+210pt, -90pt) {Fortify region};
\node[draw=black!50,rectangle,very thick,rounded corners=0.1mm,anchor=north] (End2) at (0.5\paperwidth+210pt, -140pt) {End turn}; \node[draw=black!50,rectangle,very thick,rounded corners=0.1mm,anchor=north] (End2) at (0.5\paperwidth+210pt, -140pt) {End turn};
\node[draw=black!50,rectangle,very thick,rounded corners=0.1mm,anchor=north] (End3) at (0.5\paperwidth+210pt, -190pt) {End game}; \node[draw=black!50,rectangle,very thick,rounded corners=0.1mm,anchor=north] (End3) at (0.5\paperwidth+210pt, -190pt) {End game};
\draw[very thick,->,dashed] (End2) -- node[right] {All regions controlled by one player} ++(End3); \draw[very thick,->,dashed] (End2) -- node[right] {All regions controlled by one player} ++(End3);
\draw[very thick,->] (Fortify) -- (End2); \draw[very thick,->] (Fortify) -- (End2);
\draw[very thick,->,dashed] (Act2) -- (0.5\paperwidth+112pt, 130pt) -- node[below] {Reinf. remaining} ++ (Reinf2); \draw[very thick,->,dashed] (Act2) -- (0.5\paperwidth+112pt, 130pt) -- node[below] {Reinf. remaining} ++ (Reinf2);
\draw[very thick,->,dashed] (0.5\paperwidth+112pt, 130pt) -- (0.5\paperwidth+112pt, 60pt) -- (Attack1); \draw[very thick,->,dashed] (0.5\paperwidth+112pt, 130pt) -- (0.5\paperwidth+112pt, 60pt) -- (Attack1);
\draw[very thick,->,dashed] (0.5\paperwidth+112pt, 60pt) -- (0.5\paperwidth+112pt, -100pt) -- (Fortify); \draw[very thick,->,dashed] (0.5\paperwidth+112pt, 60pt) -- (0.5\paperwidth+112pt, -100pt) -- (Fortify);
@ -485,7 +485,7 @@ In the case of a fixed base, further speedup can be gained through pre-computati
\Function{FixedBaseExp}{$b$} \Function{FixedBaseExp}{$b$}
\State $index \gets 0$ \State $index \gets 0$
\State $counter \gets 1$ \State $counter \gets 1$
\While{$b \neq 0$} \While{$b \neq 0$}
\If {$b \equiv 1 \mod 2$} \If {$b \equiv 1 \mod 2$}
\State $ctr \gets ctr \times h[i]$ \State $ctr \gets ctr \times h[i]$
@ -585,7 +585,7 @@ Paillier is implemented by four classes: \texttt{PubKey}, \texttt{PrivKey}, \tex
A large part of Risk involves random behaviour dictated by rolling some number of dice. To achieve this, a fair protocol must be used to generate random values consistently across each peer without any peer being able to manipulate the outcomes. A large part of Risk involves random behaviour dictated by rolling some number of dice. To achieve this, a fair protocol must be used to generate random values consistently across each peer without any peer being able to manipulate the outcomes.
This is achieved through bit-commitment and properties of $\mathbb{Z}_n$. The protocol for two peers is as follows, and generalises to $n$ peers. This is achieved with a standard application of bit-commitment, and properties of $\mathbb{Z}_n$. The protocol for two peers is as follows, and generalises to $n$ peers.
\begin{protocol}[Shared random values]\label{protocol2} \begin{protocol}[Shared random values]\label{protocol2}
\begin{center} \begin{center}
@ -677,25 +677,25 @@ The first proof to discuss is the honest-verifier protocol to prove knowledge th
\begin{protocol}[Proof of zero]\label{protocol0} \begin{protocol}[Proof of zero]\label{protocol0}
\begin{center} \begin{center}
\begin{tikzpicture}[every node/.append style={very thick,rounded corners=0.1mm}] \begin{tikzpicture}[every node/.append style={very thick,rounded corners=0.1mm}]
\node[draw,rectangle] (P) at (0,0) {Prover}; \node[draw,rectangle] (P) at (0,0) {Prover};
\node[draw,rectangle] (V) at (6,0) {Verifier}; \node[draw,rectangle] (V) at (6,0) {Verifier};
\node[draw=blue!50,rectangle,thick,text width=5.05cm] (v) at (0,-1.5) {$r \in \mathbb{Z}_n^*$ with $c = r^n \mod n^2$}; \node[draw=blue!50,rectangle,thick,text width=5.05cm] (v) at (0,-1.5) {$r \in \mathbb{Z}_n^*$ with $c = r^n \mod n^2$};
\draw [->,very thick] (0,-3)--node [auto] {$c$}++(6,0); \draw [->,very thick] (0,-3)--node [auto] {$c$}++(6,0);
\node[draw=blue!50,rectangle,thick] (r) at (0,-4) {Choose random $r^* \in \mathbb{Z}_n^*$}; \node[draw=blue!50,rectangle,thick] (r) at (0,-4) {Choose random $r^* \in \mathbb{Z}_n^*$};
\draw [->,very thick] (0,-5)--node [auto] {$a = (r^*)^n \mod n^2$}++(6,0); \draw [->,very thick] (0,-5)--node [auto] {$a = (r^*)^n \mod n^2$}++(6,0);
\node[draw=blue!50,rectangle,thick] (e) at (6,-6) {Choose random $e$}; \node[draw=blue!50,rectangle,thick] (e) at (6,-6) {Choose random $e$};
\draw [<-,very thick] (0,-7)--node [auto] {$e$}++(6,0); \draw [<-,very thick] (0,-7)--node [auto] {$e$}++(6,0);
\draw [->,very thick] (0,-8)--node [auto] {$z = r^*r^e \mod n$}++(6,0); \draw [->,very thick] (0,-8)--node [auto] {$z = r^*r^e \mod n$}++(6,0);
\node[draw=blue!50,rectangle,thick,text width=5cm] (verify) at (6,-9) {Verify $z, c, a$ coprime to $n$\\ Verify $z^n \equiv ac^e \mod n^2$}; \node[draw=blue!50,rectangle,thick,text width=5cm] (verify) at (6,-9) {Verify $z, c, a$ coprime to $n$\\ Verify $z^n \equiv ac^e \mod n^2$};
\node[draw=none] (term) at (0,-9) {}; \node[draw=none] (term) at (0,-9) {};
\fill (term) circle [radius=2pt]; \fill (term) circle [radius=2pt];
\draw [very thick] (P)-- (v)-- (r)-- (0,-9); \draw [very thick] (P)-- (v)-- (r)-- (0,-9);
\draw [very thick] (V)-- (e)-- (verify)-- (6,-9); \draw [very thick] (V)-- (e)-- (verify)-- (6,-9);
\end{tikzpicture} \end{tikzpicture}
@ -1007,49 +1007,49 @@ We can apply the Fiat-Shamir heuristic to make proofs of zero non-interactive \c
very thick,fill=white, very thick,fill=white,
rounded corners=0.1mm, rounded corners=0.1mm,
minimum height=20pt}] minimum height=20pt}]
\node[draw,rectangle] (P1) at (0,-0.5) {Player 1}; \node[draw,rectangle] (P1) at (0,-0.5) {Player 1};
\node[draw,rectangle] (V) at (6,-0.5) {World}; \node[draw,rectangle] (V) at (6,-0.5) {World};
\node[draw,rectangle] (P2) at (12,-0.5) {Player 2}; \node[draw,rectangle] (P2) at (12,-0.5) {Player 2};
\draw [very thick] (P1)-- (0,-15); \draw [very thick] (P1)-- (0,-15);
\draw [very thick] (V) -- (6,-15); \draw [very thick] (V) -- (6,-15);
\draw [very thick] (P2)-- (12,-15); \draw [very thick] (P2)-- (12,-15);
\draw [->,very thick] (0,-3)--node [auto] {\hyperref[protocol1]{Protocol~\ref*{protocol1}}}++(6,0); \draw [->,very thick] (0,-3)--node [auto] {\hyperref[protocol1]{Protocol~\ref*{protocol1}}}++(6,0);
\draw [->,very thick] (6,-3)--(12,-3); \draw [->,very thick] (6,-3)--(12,-3);
\node[draw=blue!50,rectangle] at (0,-2) {Reinforce regions}; \node[draw=blue!50,rectangle] at (0,-2) {Reinforce regions};
\draw [<->,very thick] (12,-4)-- node[above] {\hyperref[protocol0]{Protocol~\ref*{protocol0}} (neighbouring counts)} ++ (-12,0); \draw [<->,very thick] (12,-4)-- node[above] {\hyperref[protocol0]{Protocol~\ref*{protocol0}} (neighbouring counts)} ++ (-12,0);
\node[draw=blue!50,rectangle] at (0,-5) {Attack Player 2}; \node[draw=blue!50,rectangle] at (0,-5) {Attack Player 2};
\draw [->,very thick] (0,-6)--node [auto] {\hyperref[protocol4]{Protocol~\ref*{protocol4}}}++(6,0); \draw [->,very thick] (0,-6)--node [auto] {\hyperref[protocol4]{Protocol~\ref*{protocol4}}}++(6,0);
\draw [->,very thick] (6,-6)--++(6,0); \draw [->,very thick] (6,-6)--++(6,0);
\node[draw=blue!50,rectangle] at (12,-7) {Send defence}; \node[draw=blue!50,rectangle] at (12,-7) {Send defence};
\draw [->,very thick] (12,-8)--node [above] {\hyperref[protocol4]{Protocol~\ref*{protocol4}}}++(-6,0); \draw [->,very thick] (12,-8)--node [above] {\hyperref[protocol4]{Protocol~\ref*{protocol4}}}++(-6,0);
\draw [->,very thick] (6,-8)--++(-6,0); \draw [->,very thick] (6,-8)--++(-6,0);
\path (0,-9)-- node[above] {\hyperref[protocol2]{Protocol~\ref*{protocol2}} (resolve dice)} ++ (12,0); \path (0,-9)-- node[above] {\hyperref[protocol2]{Protocol~\ref*{protocol2}} (resolve dice)} ++ (12,0);
\draw [<->,very thick] (0,-9)--++ (6,0); \draw [<->,very thick] (0,-9)--++ (6,0);
\draw [<->,very thick] (6,-9)--++ (6,0); \draw [<->,very thick] (6,-9)--++ (6,0);
\path (0,-10)-- node[above] {\hyperref[protocol4]{Protocol~\ref*{protocol4}} (prove maintained ownership)} ++ (12,0); \path (0,-10)-- node[above] {\hyperref[protocol4]{Protocol~\ref*{protocol4}} (prove maintained ownership)} ++ (12,0);
\draw [<->,very thick] (0,-10)--++ (6,0); \draw [<->,very thick] (0,-10)--++ (6,0);
\draw [<->,very thick] (6,-10)--++ (6,0); \draw [<->,very thick] (6,-10)--++ (6,0);
\node[draw=blue!50,rectangle] at (0,-11) {Fortify}; \node[draw=blue!50,rectangle] at (0,-11) {Fortify};
\draw [->,very thick] (0,-12)--node [auto] {\hyperref[protocol3]{Protocol~\ref*{protocol3}}}++(6,0); \draw [->,very thick] (0,-12)--node [auto] {\hyperref[protocol3]{Protocol~\ref*{protocol3}}}++(6,0);
\draw [->,very thick] (6,-12)--(12,-12); \draw [->,very thick] (6,-12)--(12,-12);
\draw [<->,very thick] (12,-13)-- node[above] {\hyperref[protocol0]{Protocol~\ref*{protocol0}} (neighbouring counts)} ++ (-12,0); \draw [<->,very thick] (12,-13)-- node[above] {\hyperref[protocol0]{Protocol~\ref*{protocol0}} (neighbouring counts)} ++ (-12,0);
\path (0,-14)--node [auto] {\hyperref[protocol4]{Protocol~\ref*{protocol4}} (prove non-negative)}++(12,0); \path (0,-14)--node [auto] {\hyperref[protocol4]{Protocol~\ref*{protocol4}} (prove non-negative)}++(12,0);
\draw [->,very thick] (0,-14)--++(6,0); \draw [->,very thick] (0,-14)--++(6,0);
\draw [->,very thick] (6,-14)--++(6,0); \draw [->,very thick] (6,-14)--++(6,0);
\fill (0,-15) circle [radius=2pt] ; \fill (0,-15) circle [radius=2pt] ;
\fill (6,-15) circle [radius=2pt] ; \fill (6,-15) circle [radius=2pt] ;
\fill (12,-15) circle [radius=2pt] ; \fill (12,-15) circle [radius=2pt] ;
@ -1227,7 +1227,7 @@ Multi-round proofs combining set membership and graph isomorphism are among the
\section{Domain} \section{Domain}
The protocols devised are effective in the target domain of online games. With multi-round proofs of 24 rounds, players can be reasonably confident that other players are not cheating. The protocols devised are effective in the target domain of online games. With multi-round proofs of 24 rounds, players can be reasonably confident that other players are not cheating.
For the most part, the protocols shown run in a time-frame that would not disrupt the experience, with the exception of the bit length proof. With additional work, this proof could be replaced with a Bulletproof \cite{bulletproofs}, which may use less bandwidth and perform faster. For the most part, the protocols shown run in a time-frame that would not disrupt the experience, with the exception of the bit length proof. With additional work, this proof could be replaced with a Bulletproof \cite{bulletproofs}, which may use less bandwidth and perform faster.
@ -1290,6 +1290,8 @@ Using a language that can interact with the operating system would have further
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 computers in use today. 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. 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 computers in use today. 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.
\emph{Final word count: 9,086}
\bibliography{Dissertation} \bibliography{Dissertation}
\end{document} \end{document}