Fixed most other stuff that I broke

This commit is contained in:
jude
2023-03-05 17:19:37 +00:00
parent 96fe20503a
commit c0f2c4bbef
9 changed files with 88 additions and 50 deletions

Binary file not shown.

View File

@ -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}