Add bcdg range proof
This commit is contained in:
@ -638,11 +638,11 @@ Players should prove a number of properties of their game state to each other to
|
||||
|
||||
(2) and (4) are both covered by the proof above. (3) is okay between two players, as it is a subcase of (2). But in the case of more players, the availability of units should be proven. One way to achieve this is with a range proof.
|
||||
|
||||
\cite{Boudot2000EfficientPT} demonstrates a proof that some given ciphertext lies within an interval $[-\ell, 2\ell]$, where $\ell$ is some public value. This proof can easily be manipulated into a proof that a value lies within the interval $[n, 3\ell + n]$ from the additive homomorphic property. By selecting a sufficiently high $\ell$ and appropriate $n$, this proof is appropriate for proving to other players that the number of units being used in an attack is valid.
|
||||
\cite[Section~2]{bcdg1987} demonstrates a proof that some given ciphertext lies within an interval $[-\ell, 2\ell]$, where $\ell$ is some public value. This proof can easily be manipulated into a proof that a value lies within the interval $[n, 3\ell + n]$ from the additive homomorphic property. By selecting a sufficiently high $\ell$ and appropriate $n$, this proof is appropriate for proving to other players that the number of units being used in an attack is valid.
|
||||
|
||||
\subsection{Range proof}
|
||||
|
||||
\cite{Boudot2000EfficientPT}'s proof is a multi-round proof more similar in structure to the graph isomorphism proof presented in \cite{10.1145/116825.116852}. We select public parameter $\ell$ to be some sufficiently high value that a player's unit count should not exceed during play: an appropriate choice may be 1000. Select $n$ as the number of units that the player is defending with, or in the case of attacking, let $n$ be the number of units that the player is attacking with plus 1 (as is required by the rules of Risk). %todo
|
||||
\cite{bcdg1987}'s proof is a multi-round proof more similar in structure to the graph isomorphism proof presented in \cite{10.1145/116825.116852}. We select public parameter $\ell$ to be some sufficiently high value that a player's unit count should not exceed during play: an appropriate choice may be 1000. Select $n$ as the number of units that the player is defending with, or in the case of attacking, let $n$ be the number of units that the player is attacking with plus 1 (as is required by the rules of Risk). %todo
|
||||
|
||||
\subsection{Cheating with negative values}
|
||||
|
||||
@ -680,7 +680,7 @@ This protocol has the following properties, given that the proof of zero from be
|
||||
Additionally, we can consider this protocol perfect zero-knowledge.
|
||||
|
||||
\begin{proposition}
|
||||
In the random oracle model, \hyperref[protocol1]{Protocol~\ref*{protocol1}} is perfect zero-knowledge.
|
||||
In the random-oracle and honest-verifier models, \hyperref[protocol1]{Protocol~\ref*{protocol1}} is perfect zero-knowledge.
|
||||
\end{proposition}
|
||||
|
||||
\begin{proof}
|
||||
@ -699,6 +699,12 @@ Additionally, we can consider this protocol perfect zero-knowledge.
|
||||
|
||||
In reality, as we are using Jurik's form of Paillier, the best we can hope for is computational zero-knowledge, as Jurik's form relies upon the computational indistinguishability of the sequence generated by powers of $h$ to random powers.
|
||||
|
||||
\subsection{Extending \hyperref[protocol1]{Protocol~\ref*{protocol1}} for adjacency}
|
||||
|
||||
Performing a "fortify" action is a more complicated variant of the "reinforce" action. We devise a modified
|
||||
|
||||
Firstly, the set being proven on changes form to $k, -k, 0, \dots, 0$, for a movement of $k$ units from one region to another. The challenges then change form to be proving that either these sum to zero, or that all but two are zero, with the remaining pair summing to zero (this appropriately hides the true value of $k$).
|
||||
|
||||
\subsection{Optimising}
|
||||
|
||||
It is preferred that these proofs can be performed with only a few communications: this issue is particularly prevalent here as this protocol requires multiple rounds to complete. The independence of each round on the next is a beneficial property, as it means the proof can be performed in parallel, so the prover transmits \textit{all} of their $\psi$'s, then the verifier transmits all of their challenges. However, still is the issue of performing proofs of zero.
|
||||
@ -816,15 +822,20 @@ All measurements were taken on Brave 1.50.114 (Chromium 112.0.5615.49) 64-bit, u
|
||||
\begin{table}
|
||||
\fontsize{10pt}{10pt}\selectfont
|
||||
\caption{Time\parnote{$|n| = 4096$ uses a less-optimised encryption method, as the browser frequently timed out attempting to pre-compute for the more-optimised version.} to process proofs}
|
||||
\begin{tabularx}{\hsize}{c *6{>{\Centering}X}}
|
||||
\begin{tabularx}{\hsize}{c *8{>{\Centering}X}}
|
||||
\toprule
|
||||
\multirow{2}{*}{Modulus size} & \multicolumn{2}{c}{Proof-of-zero non-interactive} & \multicolumn{2}{c}{\hyperref[protocol1]{Protocol~\ref*{protocol1}} with $t = 24$} & \multicolumn{2}{c}{\hyperref[protocol1]{Protocol~\ref*{protocol1}} with $t = 48$} \tabularnewline
|
||||
\cmidrule(l){2-3}\cmidrule(l){4-5}\cmidrule(l){6-7}
|
||||
& Prover & Verifier & Prover & Verifier & Prover & Verifier \\
|
||||
\multirow{2}{*}{Modulus size} &
|
||||
\multicolumn{2}{c}{Proof-of-zero non-interactive} &
|
||||
\multicolumn{2}{c}{\hyperref[protocol1]{Protocol~\ref*{protocol1}} with $t = 24$} &
|
||||
\multicolumn{2}{c}{\hyperref[protocol1]{Protocol~\ref*{protocol1}} with $t = 48$} &
|
||||
\multicolumn{2}{c}{BCDG Range with $t = 24$}
|
||||
\tabularnewline
|
||||
\cmidrule(l){2-3}\cmidrule(l){4-5}\cmidrule(l){6-7}\cmidrule(l){8-9}
|
||||
& Prover & Verifier & Prover & Verifier & Prover & Verifier & Prover & Verifier \\
|
||||
\midrule
|
||||
$|n| = 1024$ & 10ms & 18ms & 1,420ms & 2,140ms & 2,900ms & 4,270ms \\
|
||||
$|n| = 2048$ & 44ms & 68ms & 6,390ms & 8,140ms & 13,200ms & 16,200ms \\
|
||||
$|n| = 4096$ & 225ms & 292ms & 41,500ms & 34,400ms & 83,200ms & 68,400ms \\
|
||||
$|n| = 1024$ & 10ms & 18ms & 1,420ms & 2,140ms & 2,900ms & 4,270ms & 443ms & 655ms \\
|
||||
$|n| = 2048$ & 44ms & 68ms & 6,390ms & 8,140ms & 13,200ms & 16,200ms & 1,980ms & 2,400ms \\
|
||||
$|n| = 4096$ & 225ms & 292ms & 41,500ms & 34,400ms & 83,200ms & 68,400ms & 14,300ms & 11,400ms \\
|
||||
\bottomrule
|
||||
\end{tabularx}
|
||||
\parnotes
|
||||
@ -834,15 +845,16 @@ All measurements were taken on Brave 1.50.114 (Chromium 112.0.5615.49) 64-bit, u
|
||||
\fontsize{10pt}{10pt}\selectfont
|
||||
\caption{Byte size\parnote{1 UTF-16 character, as used by ECMAScript \cite[Section~6.1.4]{ecma2024262}, is 2 or more bytes.} of encoded proofs}
|
||||
\label{table3}
|
||||
\begin{tabularx}{\hsize}{c *6{>{\Centering}X}}
|
||||
\begin{tabularx}{\hsize}{c *8{>{\Centering}X}}
|
||||
\toprule
|
||||
\multirow{2}{*}{Modulus size} & \multicolumn{2}{c}{Proof-of-zero non-interactive} & \multicolumn{2}{c}{\hyperref[protocol1]{Protocol~\ref*{protocol1}} with $t = 24$} & \multicolumn{2}{c}{\hyperref[protocol1]{Protocol~\ref*{protocol1}} with $t = 48$} \tabularnewline
|
||||
\cmidrule(l){2-3}\cmidrule(l){4-5}\cmidrule(l){6-7}
|
||||
& JSON & with LZ-String & JSON & with LZ-String & JSON & with LZ-String \\
|
||||
\multirow{2}{*}{Modulus size} & \multicolumn{2}{c}{Proof-of-zero non-interactive} & \multicolumn{2}{c}{\hyperref[protocol1]{Protocol~\ref*{protocol1}} with $t = 24$} & \multicolumn{2}{c}{\hyperref[protocol1]{Protocol~\ref*{protocol1}} with $t = 48$} & \multicolumn{2}{c}{BCDG Range with $t = 24$}
|
||||
\tabularnewline
|
||||
\cmidrule(l){2-3}\cmidrule(l){4-5}\cmidrule(l){6-7}\cmidrule(l){8-9}
|
||||
& JSON & with LZ-String & JSON & with LZ-String & JSON & with LZ-String & JSON & with LZ-String \\
|
||||
\midrule
|
||||
$|n| = 1024$ & 1,617B & 576B & 338,902B & 95,738B & 673,031B & 186,857B \\
|
||||
$|n| = 2048$ & 3,153B & 1,050B & 662,233B & 187,333B & 1,315,463B & 365,086B \\
|
||||
$|n| = 4096$ & 6,226B & 1,999B & 1,315,027B & 368,646B & 2,609,131B & 721,891B \\
|
||||
$|n| = 1024$ & 1,617B & 576B & 338,902B & 95,738B & 673,031B & 186,857B & 123,354B & 34,857B \\
|
||||
$|n| = 2048$ & 3,153B & 1,050B & 662,233B & 187,333B & 1,315,463B & 365,086B & 252,230B & 70,868B \\
|
||||
$|n| = 4096$ & 6,226B & 1,999B & 1,315,027B & 368,646B & 2,609,131B & 721,891B & 484,117B & 135,990B \\
|
||||
\bottomrule
|
||||
\end{tabularx}
|
||||
\parnotes
|
||||
|
Reference in New Issue
Block a user