Something
This commit is contained in:
parent
9e184e8aa6
commit
7d9531f0d9
@ -232,3 +232,39 @@ doi={10.1109/SP.2014.36}}
|
||||
abstract="In this paper we describe simple identification and signature schemes which enable any user to prove his identity and the authenticity of his messages to any other user without shared or public keys. The schemes are provably secure against any known or chosen message attack if factoring is difficult, and typical implementations require only 1{\%} to 4{\%} of the number of modular multiplications required by the RSA scheme. Due to their simplicity, security and speed, these schemes are ideally suited for microprocessor-based devices such as smart cards, personal computers, and remote control systems.",
|
||||
isbn="978-3-540-47721-1"
|
||||
}
|
||||
|
||||
@misc{tc39,
|
||||
author = {TC39},
|
||||
title = {BigInt: Arbitrary precision integers in JavaScript},
|
||||
year = {2020},
|
||||
publisher = {GitHub},
|
||||
journal = {GitHub repository},
|
||||
howpublished = {\url{https://github.com/tc39/proposal-bigint}},
|
||||
}
|
||||
|
||||
@article{RABIN1980128,
|
||||
title = {Probabilistic algorithm for testing primality},
|
||||
journal = {Journal of Number Theory},
|
||||
volume = {12},
|
||||
number = {1},
|
||||
pages = {128-138},
|
||||
year = {1980},
|
||||
issn = {0022-314X},
|
||||
doi = {https://doi.org/10.1016/0022-314X(80)90084-0},
|
||||
url = {https://www.sciencedirect.com/science/article/pii/0022314X80900840},
|
||||
author = {Michael O Rabin},
|
||||
abstract = {We present a practical probabilistic algorithm for testing large numbers of arbitrary form for primality. The algorithm has the feature that when it determines a number composite then the result is always true, but when it asserts that a number is prime there is a provably small probability of error. The algorithm was used to generate large numbers asserted to be primes of arbitrary and special forms, including very large numbers asserted to be twin primes. Theoretical foundations as well as details of implementation and experimental results are given.}
|
||||
}
|
||||
|
||||
@article{damgard2003,
|
||||
author = {Damgård, Ivan and Jurik, Mads and Nielsen, Jesper},
|
||||
year = {2003},
|
||||
month = {04},
|
||||
pages = {371-385},
|
||||
title = {A generalization of Paillier’s public-key system with applications to electronic voting},
|
||||
volume = {9},
|
||||
journal = {International Journal of Information Security},
|
||||
doi = {10.1007/s10207-010-0119-9}
|
||||
}
|
||||
|
||||
@book{schneier_1996, place={Estados Unidos}, title={Applied cryptography}, publisher={John Wiley}, author={Schneier, Bruce}, year={1996}}
|
Binary file not shown.
@ -4,6 +4,7 @@
|
||||
\usepackage{amsmath}
|
||||
\usepackage{amssymb}
|
||||
\usepackage{amsthm}
|
||||
\usepackage{tikz}
|
||||
|
||||
\DeclareMathOperator{\lcm}{lcm}
|
||||
|
||||
@ -256,22 +257,32 @@ Despite this approach being centralised, it does emulate a fully peer-to-peer en
|
||||
|
||||
In particular, the final point allows for the use of purely JSON messages, which are readily parsed and processed by the client-side JavaScript.
|
||||
|
||||
\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.
|
||||
|
||||
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.
|
||||
|
||||
\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.
|
||||
|
||||
In 2020, %reference
|
||||
ECMAScript introduced \texttt{BigInt}, which are, as described in the spec, "[integers which] may be any size and are not limited to a particular bit-width". Whilst this does not hold true in common ECMAScript implementations (such as V8), these "big integers" still provide sufficient precision for the Paillier cryptosystem, given some optimisations and specialisations are made with regards to the Paillier algorithm and in particular the modular exponentiation operation.
|
||||
In 2020,
|
||||
ECMAScript introduced \texttt{BigInt} \citep{tc39}, which are, as described in the spec, "arbitrary precision integers". Whilst this does not hold true in common ECMAScript implementations (such as Chrome's V8), these "big integers" still provide sufficient precision for the Paillier cryptosystem, given some optimisations and specialisations are made with regards to the Paillier algorithm and in particular the modular exponentiation operation.
|
||||
|
||||
\subsection{Optimising modular exponentiation}
|
||||
It must be noted that \texttt{BigInt} is inappropriate for cryptography in practice, due to the possibility of timing attacks as operations are not necessarily constant time \citep{tc39}. In particular, modular exponentiation is non-constant time, and operates frequently on secret data. A savvy attacker may be able to use this to leak information about an adversary's private key.
|
||||
|
||||
% todo
|
||||
\subsection{Modular exponentiation}
|
||||
|
||||
As \texttt{BigInt}'s V8 implementation does not optimise modular exponentiation, we employ the use of addition chaining, as described in \cite{schneier_1996}. Addition chaining breaks a modular exponentiation into repeated square-and-modulo operations, which are computationally inexpensive to perform.
|
||||
|
||||
The number of operations is dependent primarily on the size of the exponent. For an exponent of bit length $L$, somewhere between $L$ and $2L$ multiply-and-modulo operations are performed, which gives overall a logarithmic time complexity supposing bit-shifts and multiply-and-modulo are constant time operations.
|
||||
|
||||
\subsection{Generating large primes}
|
||||
|
||||
I chose to use primes of length 2048 bits. This is on the upper end of typical prime sizes for cryptography, as this generates $n = pq$ of length 4096 bits.
|
||||
I chose to use primes of length 2048 bits. This is a typical prime size for public-key cryptography, as this generates a modulus $n = pq$ of length 4096 bits.
|
||||
|
||||
Generating these primes is a basic application of the Miller-Rabin primality test. This produces probabilistic primes, however upon completing sufficiently many rounds of verification, the likelihood of these numbers actually not being prime is dwarfed by the likelihood of hardware failure.
|
||||
Generating these primes is a basic application of the Rabin-Miller primality test \citep{RABIN1980128}. This produces probabilistic primes, however upon completing sufficiently many rounds of verification, the likelihood of these numbers actually not being prime is dwarfed by the likelihood of hardware failure.
|
||||
|
||||
\subsection{Public key}
|
||||
|
||||
@ -284,7 +295,7 @@ The Paillier cryptosystem is otherwise generic over the choice of primes $p, q$.
|
||||
\end{proposition}
|
||||
|
||||
\begin{proof}
|
||||
WLOG, assume $p > q$. Suppose $\gcd(pq, (p - 1)(q - 1)) \neq 1$. Then, $q \mid p - 1$. However, the bit-lengths of $p, q$ are identical. So $\frac{1}{2}(p - 1) < q$. This is a contradiction to $q \mid p - 1$ (as 2 is the smallest possible divisor), and so we must have $\gcd(pq, (p - 1)(q - 1)) = 1$ as required.
|
||||
Without loss of generality, assume $p > q$. Suppose $\gcd(pq, (p - 1)(q - 1)) \neq 1$. Then, $q \mid p - 1$. However, the bit-lengths of $p, q$ are identical. So $\frac{1}{2}(p - 1) < q$. This is a contradiction to $q \mid p - 1$ (as 2 is the smallest possible divisor), and so we must have $\gcd(pq, (p - 1)(q - 1)) = 1$ as required.
|
||||
\end{proof}
|
||||
|
||||
As the prime generation routine generates primes of equal length, this property is therefore guaranteed. The next optimisation is to select $g = 1 + n$.
|
||||
@ -301,7 +312,7 @@ The selection of such $g$ is ideal, as the binomial expansion property helps to
|
||||
|
||||
\subsection{Encryption}
|
||||
|
||||
The cyphertext is, in general, computed as $c = g^m r^n \mod n^2$ for $r < n$ some random blinding factor. This computation is exceptionally irritating to perform however in JavaScript, even with big integer types. We instead compute $c = (r^n \mod n^2) \cdot (g^m \mod n^2) \mod n^2$, and propose that this is equivalent.
|
||||
The cyphertext is, in general, computed as $c = g^m r^n \mod n^2$ for $r < n$ some random secret value. To make this easier to compute, we compute the equivalent value $c = (r^n \mod n^2) \cdot (g^m \mod n^2) \mod n^2$.
|
||||
|
||||
\subsection{Private key}
|
||||
|
||||
@ -311,19 +322,60 @@ We are also interested in the ability to compute $\mu = \lambda^{-1} \mod n$ as
|
||||
|
||||
\subsection{Decryption}
|
||||
|
||||
Let $c$ be the cyphertext. The corresponding plaintext is computed as $m = L(c^\lambda \mod n^2) \cdot \mu \mod n$, where $L(x) = \frac{x - 1}{n}$. Fortunately, unlike the encryption case, this is relatively simple to compute in JavaScript. We now show that the "simplified" encryption is compatible with this decryption.
|
||||
Let $c$ be the cyphertext. The corresponding plaintext is computed as $m = L(c^\lambda \mod n^2) \cdot \mu \mod n$, where $L(x) = \frac{x - 1}{n}$. This is relatively simple to compute in JavaScript.
|
||||
|
||||
\begin{proposition}
|
||||
The cyphertexts provided are equivalent up to decryption.
|
||||
\end{proposition}
|
||||
\subsection{Proof system}
|
||||
|
||||
\begin{proof}
|
||||
Let $c = g^m r^n \mod n^2$ and $c' = (r^n \mod n^2) \cdot (g^m \mod n^2) \mod n^2$. Then, \begin{align*}
|
||||
L(c^\lambda \mod n^2) \cdot \mu &\equiv L((g^m r^n)^\lambda \mod n^2) \cdot \mu \mod n \\
|
||||
&\equiv L(g^{\lambda m} r^{\lambda n} \mod n^2) \cdot \lambda^{(p - 1)(q - 1)} \mod n
|
||||
\end{align*}
|
||||
%todo
|
||||
\end{proof}
|
||||
The proof system is that of \cite{damgard2003}. The authors give a method to prove knowledge of the encrypted value. The importance of using a zero-knowledge method for this is that it verifies knowledge to a single party. This party should be an honest verifier: this is an assumption we have made of the context, but in general this is not true, and so this provides an attack surface for colluding parties.
|
||||
|
||||
The proof system presented is an interactive proof for a given cyphertext $c$ being an encryption of 0.
|
||||
|
||||
\begin{center}
|
||||
\begin{tikzpicture}[every node/.append style={very thick,rounded corners=0.1mm}]
|
||||
|
||||
\node[draw,rectangle] (P) at (0,0) {Prover};
|
||||
\node[draw,rectangle] (V) at (6,0) {Verifier};
|
||||
|
||||
\node[draw=blue!50,rectangle,thick] (v) at (0,-2) {$r \in \mathbb{Z}_n^*$ with $c = r^n$ (cyphertext)};
|
||||
\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^*$};
|
||||
\draw [->,very thick] (0,-5)--node [auto] {$a = (r^*)^n$}++(6,0);
|
||||
|
||||
\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,-8)--node [auto] {$z = r^*r^e$}++(6,0);
|
||||
\node[draw=blue!50,rectangle,thick,text width=6cm] (verify) at (6,-9) {Verify $z, c, a$ coprime to $n$\\ Verify $r^z \equiv ac^e \mod n^2$};
|
||||
|
||||
\node[draw=none] (term) at (0,-9) {};
|
||||
\fill (term) circle [radius=2pt];
|
||||
|
||||
\draw [very thick] (P)-- (v)-- (r)-- (0,-9);
|
||||
\draw [very thick] (V)-- (e)-- (verify)-- (6,-9);
|
||||
\end{tikzpicture}
|
||||
\end{center}
|
||||
|
||||
Then, a proof for the following homologous problem can be trivially constructed: given some cyphertext $c = g^mr^n \mod n^2$, prove that the text $cg^{-m} \mod n^2$ is an encryption of 0.
|
||||
|
||||
% Furthermore, the above protocol can be made non-interactive using the Fiat-Shamir heuristic \citep{fiatshamir}. (this contradicts the lit review)
|
||||
|
||||
\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}
|
||||
\item The number of reinforcements placed during the first stage of a turn.
|
||||
|
||||
\item The number of units on a region neighbouring another player.
|
||||
|
||||
\item The number of units lost during an attack/defence.
|
||||
|
||||
\item The number of units available for an attack/defence.
|
||||
|
||||
\item The number of units moved when fortifying.
|
||||
\end{itemize}
|
||||
|
||||
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.
|
||||
|
||||
\bibliography{Dissertation}
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user