Merge pull request #12 from AAU-Dat/implementation

Implementation

Author: Maltesius

report/src/sections/04-Approach.tex

@@ -74,7 +74,7 @@ \subsection{Springproofs}\label{sec:approach-springproofs}
 First of all, we have the prover computation, where the proof is constructed.
 The construction can be seen in~\autoref{fig:ipa-prover}.
 
-\begin{figure}[ht]
+\begin{figure}[h]
 \begin{framed}
     \begin{lstlisting}[language=Python,mathescape=true,label={lst:ipa-prover}]
 $\textbf{Step 1:}$
@@ -149,7 +149,7 @@ \subsection{Springproofs}\label{sec:approach-springproofs}
 Having the proof on the blockchain allows for each validator to asynchronously verify whether it is a valid proof.
 Again, the originally proposed verifying protocol has been modified according to Springproofs, which is seen in~\autoref{fig:ipa-verifier}.
 
-\begin{figure}[ht]
+\begin{figure}[h]
 \begin{framed}
 \begin{lstlisting}[language=Python,mathescape=true,label={lst:ipa-verifier}]
 $\textbf{Step 1:}$
@@ -205,10 +205,10 @@ \subsection{Springproofs}\label{sec:approach-springproofs}
 If so, the verifier accepts the proof.
 
 
-\subsection{Shuffle security}\label{sec:approach-shuffle-security}
-The shuffle method proposed by Larsen et al.~\cite{cryptoeprint:2022/560} that was used in curdleproofs is based on the idea of shuffling a list of proposers over a set of slots.
-The shuffle itself however is not too complex.
-A formal definition of the shuffle is given in~\autoref{fig:shuffle}.
+\subsection{Shuffle security}\label{subsec:approach-shuffle-security}
+The shuffle method proposed by Larsen et al.~\cite{cryptoeprint:2022/560} that was used in Curdleproofs is based on the idea of shuffling a list of proposers over a set of slots.
+The shuffle itself, however, is not too complex.
+A formal definition of the shuffle is given in~\autoref{fig:shuffle}~\cite{cryptoeprint:2022/560}.
 
 \begin{figure}[ht]
 \begin{framed}
@@ -230,29 +230,146 @@ \subsection{Shuffle security}\label{sec:approach-shuffle-security}
 \end{figure}
 
 Here the set $(c_1, \ldots, c_n)$ is a set of ciphertexts that are shuffled over $T$ slots.
-In each slot $t$, a subset of the ciphertexts ${i_1, \ldots, i_k}$ is chosen randomly and shuffled and added back to the list of ciphertexts.
-It is then encrypts the ciphertexts again and publishes them.
+In each slot $t$, a subset of the ciphertexts ${i_1, \ldots, i_k}$ is chosen randomly, shuffled, and added back to the list of ciphertexts.
+The shuffler then re-encrypts the ciphertexts and publishes them.
 This process is repeated for $T$ slots and the shuffle is complete.
-During the $T$ shuffles some of the shufflers may be adversarial.
-This means that whenever the shuffling process is taking place a part of the shuffles may be adversarial which can be seen as not being shuffled.
-Therefore the amount of honest shuffles that happen during the shuffle process is $T_H = T - \alpha$.
-Where $\alpha$ is the amount of adversarial shufflers.
+During the $T$ shuffles, some shufflers may be adversarial.
+This means that whenever the shuffling process is taking place, a part of the shuffles may be adversarial, which can be seen as not being shuffled.
+Therefore, the number of honest shuffles that happen during the shuffle process is $T_H = T - \alpha$, where $\alpha$ is the number of adversarial tracked ciphertexts.
 
-The Shuffle is secure if none of these two events occur.
+The shuffle is secure if none of the following two events occur.
 The first event is a short backtracking, where an adversary can find the original ciphertexts from the shuffled ciphertexts.
-Since the subsets of ciphertexts are chosen randomly in each shuffle, if is enough adversarial shufflers in a row to end the process, then a shot backtrack is possible.
+Since the subsets of ciphertexts are chosen randomly in each shuffle, if there are enough adversarial shufflers in a row to end the process, then a short backtracking is possible.
 
-The second event that can occur is that since every shuffle distributes the possibility of a certain ciphertext to be in a certain slot.
-Then if a shuffle contains a lot of ciphertext with a larger than average chance of containing a certain ciphertext, then that would imply that there is a higher chance of that ciphertext being in that slot.
+The second event that can occur is related to the fact that every shuffle distributes the possibility of a certain ciphertext to be in a certain slot.
+So, if a shuffle contains a lot of ciphertexts with a larger than average chance of containing a certain ciphertext, then that would imply that there is a higher chance of that ciphertext being in that slot.
 
-It is theoretically possible to find a shuffle size and a number of shuffles given an amount of adversarial shufflers to guarantee that the shuffle is secure.
+It is theoretically possible to find a number of shuffles, given the shuffle size, and a number of adversarial shufflers, to guarantee that the shuffle is secure.
 For any $0 < \delta < 1/3$, if $T \geq 20 n / k \ln(n/\delta) + \beta $ and $ k \geq 256 \ln^2(n/\delta)(1 - \alpha/n)^{-2}$.
 If $T$ and $k$ are chosen such that the above two conditions are met, then the protocol is an $(\epsilon , \delta)$-secure $(T,n,k)$-shuffle in the presence of a $(\alpha, \beta)$-adversary where $\epsilon = 2/(n-\alpha)$.
 
 This formula is the lowest theoretically proven bound for $T$ and $k$.
-It is however possible to find lower secure values for $T$ and $k$ but this has to be done experimentally.
+Plotting numbers relevant to Whisk will show that this theoretical bound is too large to use for argumentation of security.
+It is, however, possible to find lower secure values for $T$ and $k$, but this has to be done experimentally.
 
 
 \subsection{Implementation}\label{subsec:approach-implementation}
+Implementing the above-explained CAAUrdleproofs protocol introduced some optimizations required to have the code run as fast as possible.
+These are explained in the following with a focus on how CAAUrdleproofs differentiates itself from Curdleproofs.
+Both our implementation of CAAUrdleproofs and the experiment involving the security of the shuffle are publicly available on GitHub~\footnote{\href{https://github.com/AAU-Dat/curdleproofsplus/tree/SIPA}{https://github.com/AAU-Dat/curdleproofsplus/tree/SIPA}}.
+The implementation of CAAUrdleproofs is a fork of and builds directly on the already existing Curdleproofs code.
+\subsubsection{CAAUdleproofs}
+The protocol in Curdleproofs~\cite{Curdleproofs} introduces a lot of multiscalar multiplications.
+As such, CAAUrdleproofs also introduces these multiplications.
+This allows for checking calculations of the form:
+\begin{align}
+    C\stackrel{?}{=}\mathbf{x}\times(\mathbf{g}\|\mathbf{h}\|G_T\|G_U\|H\|\mathbf{R}\|\mathbf{S}\|\mathbf{T}\|\mathbf{U})
+\end{align}
+As explained by Curdleproofs, the verifier computation can be significantly optimized by checking the multiscalar multiplications as a single check at the end of the protocol instead.
+
+CAAUrdleproofs introduced a slight difference on this topic in regard to the~\glspl{ipa}, \texttt{sameperm} and \texttt{same multiscalar}.
+In each recursive round, both the folded vectors and the commitments are being multiplied by verification scalars, $\gamma_j$.
+To keep track of which elements of the vectors are multiplied by each $\gamma_j$, a function called \texttt{get\_verification\_scalars\_bitstring} is used.
+The output of this function is a list of length $\ell$, each element with a list corresponding to the rounds in which $\gamma_j$ was multiplied to the element.
+Curdleproofs' implementation is simpler than CAAUrdleproofs' in this case.
+As Curdleproofs works on powers of two, it is always the right half of the vectors in each round that are multiplied by the challenge.
+
+The multiplication of challenges are not as easily trackable in the CAAUrdleproofs protocol.
+Here, it is necessary to simulate a run though the recursive protocol.
+Though, this should not have a big impact on performance, as it is run over vectors of small integers, and never actually has to do any multiplications.
+It is simply used as a measuring tool.
+
+\begin{figure}[ht]
+    \begin{framed}
+        \begin{lstlisting}[language=Python,mathescape=true,label={lst:ipa-verifier-optimized}]
+$\textbf{Step 1:}$
+$(\textbf{G},H)\gets$parse$(crs_{dl_{inner}})$
+$(C,D,z,\mathbf{u})\gets$parse$(\phi_{dl_{inner}})$
+$(B_C,B_D,\mathbf{\pi},c,d)\gets$parse$(\pi_{dl_{inner}})$
+$\alpha,\beta\gets$Hash$(C,D,z,B_C,B_D)$
+
+$\textbf{Step 2:}$
+$m\gets \lceil\log n\rceil$
+for $1\leq j\leq m$
+    $T,S\gets \textbf{\textit{f(}}n\textbf{\textit{)}}$
+    $n\gets \frac{|T|}{2}$
+    $(L_{C,j},L_{D,j},R_{C,j},R_{D,j})\gets$parse$(\pi_j)$
+    $\gamma_j\gets$Hash$(\pi_j)$
+    $n\gets n+\text{len}(S)$
+
+$\textbf{Step 3:}$
+$\mathbf{CP}\text{: }\mathbf{\gamma}\gets(\gamma_m,...,\gamma_1)$
+$\mathbf{CAAUP}\text{: }\mathbf{\gamma}\gets(\gamma_1,...,\gamma_m)$
+$\textit{Compute }\mathbf{s}\textit{: see below for difference}$
+
+AccumulateCheck$(\mathbf{\gamma}\times\mathbf{L}_C+(B_C+\alpha C+(\alpha^2z)H)$
+    $+\mathbf{\gamma}^{-1}\times\mathbf{R}_C\stackrel{?}{=}(c\mathbf{s}\| cd\beta)\times(\mathbf{G}\| H))$
+AccumulateCheck$(\mathbf{\gamma}\times\mathbf{L}_D+(B_D+\alpha D)$
+    $+\mathbf{\gamma}^{-1}\times\mathbf{R}_D\stackrel{?}{=}d(\mathbf{s'}\circ\mathbf{u})\times\mathbf{G})$
+$\text{return 1}$
+
+$\textbf{s-step Curdleproofs:}$
+for $1\leq j\leq n$:
+    $s_i=\sum_{j=1}^m\delta_j^{b_{i,j}}\text{, }b_{i,j}\in\{0,1\}\text{ s.t. }i=\sum_{j=1}^mb_{i,j}2^j$
+    $s'_i=\sum_{j=1}^m\delta_j^{-b_{i,j}}$
+$\textbf{s-step CAAUrdleproofs:}$
+$ActivePos\gets[(i,i)\text{, }i=1,\dots,n]$
+for $1\leq j\leq m:$
+    $h\gets\frac{2^{\lceil\log n\rceil}}{2}$
+    $f\gets n-h$
+    $nf\gets h-f$
+    $fs\gets \frac{nf}{2}$
+    for $(i,k)$ in $ActivePos$:
+        if $k\geq h:$
+            $b_{i,j}\gets1$
+            $newPos=k-h-fs$
+        else:
+            $b_{i,j}\gets0$
+            $newPos=k$
+        $nextActivePos.push((i,newPos))$
+    $ActivePos\gets nextActivePos$
+    $n\gets h$
+for $1\leq j\leq n$:
+    $s_i=\sum_{j=1}^m\delta_j^{b_{i,j}}$
+    $s'_i=\sum_{j=1}^m\delta_j^{-b_{i,j}}$
+        \end{lstlisting}
+    \end{framed}
+    \caption{Optimized verifier computation for CAAU-IPA in CAAUrdleproofs}
+    \label{fig:ipa-verifier-optimized}
+\end{figure}
+
+The protocol used in the implementation can be seen in~\autoref{fig:ipa-verifier-optimized}.
+A list, \texttt{ActivePos}, keeps track of the original index placement and its position after each fold.
+Doing this, we can run the recursion and find the correct challenges for each index, while still knowing what the original index was.
+A bit matrix,~$b_{i,j}$, is constructed as in Curdleproofs, such that the vector, $\mathbf{s}$, is made in the same way for both protocols.
+
+The vector, $\mathbf{u}$, is used for optimization in the grand product argument rather than $\mathbf{G'}$, and the \texttt{AccumulateCheck} function is used for the multiscalar multiplication optimization.
+For a thorough explanation of these, we refer to Curdleproofs~\cite{Curdleproofs}.
+
+In Curdleproofs, both the \texttt{SamePerm} and \texttt{SameMultiscalar} proof are recursive~\glspl{ipa}.
+So, the modifications and optimization used on the \texttt{SamePerm} argument are also used on the \texttt{SameMultiscalar} argument.
+This includes the split into set $T$ and $S$ before recursion, and the construction of the bit matrix, $b_{i,j}$, to keep track of multiplications on individual elements.
+
+
+\subsubsection{Shuffle Security}
+As mentioned in~\autoref{subsec:approach-shuffle-security}, the theoretically proven bound, on the necessary number of shuffles to ensure security is too high.
+Hence, as also done in~\cite{cryptoeprint:2022/560}, we implement an experiment to find the bounds, where the shuffle is secure.
+The goal of the experimental code is to find the number of honest shuffles required for security.
+
+We inherit the authors of the shuffle's terminology, and interpret each ciphertext as a cup that can contain water.
+Each cup contains an amount of water between 0 and 1.
+
+An experiment run starts with the first cup being full and the rest being empty.
+As mentioned, $\alpha$ cups are tracked by an adversary, the first $n-\alpha$ cups are called active cups, while the last $\alpha$ cups are tracked.
+So, at each shuffle, the shuffler randomly picks $k$ ciphertexts and shuffles them, also randomly.
+Meanwhile, an average of the water between the active indices of the $k$-shuffle is found.
+All active indices are given this amount of water.
+
+Now, after each shuffle, if any cup has more than $\frac{2}{n-\alpha}$ water, its position can be predicted by the adversary, hence the shuffle is insecure~\cite{cryptoeprint:2022/560}.
+If a position can be predicted, another round of shuffling is performed.
+This method is used until no cup exceeds the threshold, after which the shuffle is deemed secure.
+
+The experiment denotes how many rounds it took before the shuffle was secure.
 
+By repeating this experiment for several runs, one can experimentally say, when a shuffle with given parameters is secure.