Fixed most other stuff that I broke
This commit is contained in:
Binary file not shown.
@ -259,10 +259,14 @@ In particular, the final point allows for the use of purely JSON messages, which
|
||||
|
||||
\subsection{Message structure}
|
||||
|
||||
Messages are given a fixed structure to make processing simpler. Each JSON message holds an \texttt{author} field, being the sender's ID, and an \texttt{action}, which at a high level dictates how each client should process the message.
|
||||
Messages are given a fixed structure to make processing simpler. Each JSON message holds an \texttt{author} field, being the sender's ID; a message ID to prevent replay attacks and associate related messages; and an \texttt{action}, which at a high level dictates how each client should process the message.
|
||||
|
||||
The action more specifically is one of \texttt{ANNOUNCE}, \texttt{DISCONNECT}, \texttt{KEEPALIVE}, \texttt{RANDOM}, and \texttt{ACT}. The first three of these are used for managing the network by ensuring peers are aware of each other and know the state of the network. \texttt{RANDOM} is designated to be used by the shared-random-value subprotocol defined later. \texttt{ACT} is used by players to submit actions for their turn during gameplay.
|
||||
|
||||
Each message is also signed to verify the author. This is a standard application of RSA. A hash of the message is taken, then encrypted with the private key. This can be verified with the public key.
|
||||
|
||||
RSA keys are accepted by peers on a first-seen basis.
|
||||
|
||||
\subsection{Paillier}
|
||||
|
||||
Paillier requires the calculation of two large primes for the generation of public and private key pairs. ECMAScript typically stores integers as floating point numbers, giving precision up to $2^{53}$. This is clearly inappropriate for the generation of sufficiently large primes.
|
||||
@ -362,7 +366,7 @@ Then, a proof for the following homologous problem can be trivially constructed:
|
||||
|
||||
\subsection{Application to domain}
|
||||
|
||||
Players should prove a number of properties of their game state to each other to ensure fair play. These are as follows. \begin{itemize}
|
||||
Players should prove a number of properties of their game state to each other to ensure fair play. These are as follows. \begin{enumerate}
|
||||
\item The number of reinforcements placed during the first stage of a turn.
|
||||
|
||||
\item The number of units on a region neighbouring another player.
|
||||
@ -372,10 +376,11 @@ Players should prove a number of properties of their game state to each other to
|
||||
\item The number of units available for an attack/defence.
|
||||
|
||||
\item The number of units moved when fortifying.
|
||||
\end{itemize}
|
||||
\end{enumerate}
|
||||
|
||||
Of these, the bottom two are, more specifically, range proofs. %todo is this grammar right?
|
||||
The top three can be addressed with the protocol we have provided however.
|
||||
(4) and (5) can be generalised further as range proofs.
|
||||
|
||||
For (1), we propose the following communication sequence. The player submits pairs $(R, c_R)$ for each region they control, where $R$ is the region and $c_R$ is a cyphertext encoding the number of reinforcements to add to the region (which may be 0). Each player computes $c_{R_1} \cdot \ldots \cdot c_{R_n}$.
|
||||
|
||||
\bibliography{Dissertation}
|
||||
|
||||
|
Reference in New Issue
Block a user