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

Add bcdg range proof

Browse Source
This commit is contained in:
jude
2023-04-21 15:03:15 +01:00
parent b24d031524
commit a1eba884bc
8 changed files with 276 additions and 33 deletions
Download Patch File Download Diff File Expand all files Collapse all files

14
whitepaper/Dissertation.bib
View File

@ -396,4 +396,18 @@ doi={10.1109/SP.2014.36}}
journal={ECMA (European Association for Standardizing Information and Communication Systems), pub-ECMA: adr,},
url = {https://tc39.es/ecma262}
year={1999}
}
@inproceedings{bcdg1987,
author = {Brickell, Ernest F. and Chaum, David and Damg\r{a}rd, Ivan and Graaf, Jeroen van de},
title = {Gradual and Verifiable Release of a Secret},
year = {1987},
isbn = {3540187960},
publisher = {Springer-Verlag},
address = {Berlin, Heidelberg},
abstract = {Protocols are presented allowing someone with a secret discrete logarithm to release it, bit by bit, such that anyone can verify each bit's correctness as they receive it. This new notion of release of secrets generalizes and extends that of the already known exchange of secrets protocols. Consequently, the protocols presented allow exchange of secret discrete logs between any number of parties.The basic protocol solves an even more general problem than that of releasing a discrete log. Given any instance of a discrete log problem in a group with public group operation, the party who knows the solution can make public some interval I and convince anyone that the solution belongs to I , while releasing no additional information, such as any hint as to where in I the solution is.This can be used directly to release a discrete log, or to transfer it securely between different groups, i.e. prove that two instances are related such that knowledge of the solution to one implies knowledge of the solution to the other.We show how this last application can be used to implement a more efficient release protocol by transferring the given discrete log instance to a group with special properties. In this scenario, each bit of the secret can be verified by a single modular squaring, and unlike the direct use of the basic protocol, no interactive proofs are needed after the basic setup has been done.Finally, it is shown how the basic protocol can be used to release the factorization of a public composite number.},
booktitle = {A Conference on the Theory and Applications of Cryptographic Techniques on Advances in Cryptology},
pages = {156–166},
numpages = {11},
series = {CRYPTO '87}
}

BIN
whitepaper/Dissertation.pdf
View File

Binary file not shown.

46
whitepaper/Dissertation.tex
View File

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