Skip to content

Commit 63f9be1

Browse files
InfiniteSynthesisInfiniteSynthesis
committed
Docs: Add preliminaries
1 parent 540a875 commit 63f9be1

File tree

8 files changed

+444
-0
lines changed

8 files changed

+444
-0
lines changed

‎content/preliminaries/contd.tex‎

Lines changed: 80 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,80 @@
1+
\section{Preliminaries (Cont'd)}
2+
\label{sec:preliminaries-contd}
3+
4+
\paragraph{Global clock.}
5+
%
6+
We model synchronous processors using \funcClock (cf.~\cite{TCC:KMTZ13}).
7+
%
8+
At a high level, \funcClock maintains a round variable $\tau$ for each session, and the round forwards only when all registered parties send \funcClock the \textsc{clock-update} command.
9+
%
10+
The current time can be checked by sending a \textsc{clock-read} command.
11+
%
12+
Whenever a party who has finished the computation in a round is activated, she checks if the time from \funcClock has been forwarded; if not, she does nothing and wait for the next activation.
13+
14+
\input{functionalities/global-clock}
15+
16+
\paragraph{Diffuse functionalities.}
17+
%
18+
We model the \delay-bounded delay network with \funcDiffuse \cite{C:BMTZ17}.
19+
%
20+
Note that once a corrupted message reaches at least one honest party at round $r$, \funcDiffuse guarantees to deliver this message to all honest parties before round $r + \delay$ (i.e., honest parties keep ``echoing'' messages).
21+
%
22+
By convention, different types of messages are diffused by different functionalities, and we write $\funcDiffuse^{\mathsf{bc}}$, $\funcDiffuse^{\mathsf{tx}}$, $\funcDiffuse^{\mathsf{pb}}$, $\funcDiffuse^\pk$ to denote the network for chains, transactions, profile blocks and enclave public keys respectively.
23+
24+
\input{functionalities/diffuse}
25+
26+
\paragraph{Random oracle for PoW and its wrapper.}
27+
%
28+
Our random oracle for generating PoW follows that in~\cite{C:BMTZ17} except that now it is a shared functionality.
29+
30+
\input{functionalities/global-random-oracle}
31+
32+
In order to limit the adversary on making a certain number of queries per round, we adopt a functionality wrapper \cite{C:BMTZ17} that wraps the corresponding resource to capture such restrictions.
33+
%
34+
Note that since now \funcGRO is shared among different sessions, the adversary can ask the environment to make queries on behalf.
35+
%
36+
Hence, our wrapper \wrapper{\funcGRO} also puts restrictions on queries that are made by the environment.
37+
38+
\input{functionalities/global-random-oracle-wrapper}
39+
40+
\paragraph{Global random oracle.}
41+
%
42+
The restricted programmable and observable global random oracle \funcGrpoRO follows the modelling in~\cite{EC:CDGLN18}.
43+
%
44+
We allow the adversary to observe and program the GRO; meantime, every party (in the same session) can check if a point is programmed by calling the ``IsProgrammed'' interface.
45+
46+
\input{functionalities/global-random-oracle-rpo}
47+
48+
\paragraph{Non-interactive zero knowledge scheme \NIZK.}
49+
%
50+
The NIZKPoK scheme that we use in this paper are from \cite{TCC:LysRos22}, specifically a non-interactive, straight-line extractable (NISLE) proof
51+
system satisfying the following three properties.
52+
53+
\begin{definition}
54+
[Overwhelming Completeness]
55+
\label{def:overwhelming-completeness}
56+
57+
A NISLE proof system $\Pi^{\mathtt{SLC}}_R = (\mathtt{Setup}^H, \mathtt{Prove}^H,\allowbreak \mathtt{Verify}^H, \mathtt{SimSetup}, \mathtt{SimProve}, \mathtt{Extract})$ for relation $R$ in the random-oracle model has the \emph{overwhelming completeness} property if for any security parameter $\lambda$, any random oracle $H$, any $(x, w) \in R$, and any proof $\pi \gets \Pi^{\mathtt{SLC}}_R.\mathtt{Prove}^H(x, w)$,
58+
%
59+
\( \Pr[\Pi^{\mathtt{SLC}}_R.\mathtt{Verify}^H(x, \pi) = 1] \ge 1 - \negl(\lambda). \)
60+
\end{definition}
61+
62+
\begin{definition}
63+
[Non-Interactive Multiple SHVZK]
64+
\label{def:non-interactive-multiple-SHVZK}
65+
66+
A NISLE proof system $\Pi^{\mathtt{SLC}}_R = (\mathtt{Setup}^H,\allowbreak \mathtt{Prove}^H,\allowbreak \mathtt{Verify}^H,\allowbreak \mathtt{SimSetup},\allowbreak \mathtt{SimProve},\allowbreak \mathtt{Extract})$ for relation $R$ in the random-oracle model has the \emph{non-interactive multiple special honest-verifier zero-knowledge (NIM-SHVZK)} property if for any security parameter $\lambda$, any random oracle $H$, any PPT adversary \adv, and a bit $b \overset{\$}{\gets} \{0, 1\}$, ther exist some negligible function \negl such that $\Pr[b' = b] \le 1 /2 + \negl(\lambda)$, where $b'$ is the result of running the game $\mathsf{NIM}\text{-}\mathsf{SHVZK}^{H_*, *}_{\adv, \Pi^{\mathtt{SLC}}_R} (1^\lambda, b)$.
67+
%
68+
We say \adv wins the $\mathsf{NIM}\text{-}\mathsf{SHVZK}$ game if $\Pr[b' = b] > 1 / 2 + \negl(\lambda)$.
69+
\end{definition}
70+
71+
\begin{definition}
72+
[Non-Interactive Special Simulation-Soundness]
73+
\label{def:non-interactive-special-simulation-soundness}
74+
75+
A NISLE proof system $\Pi^{\mathtt{SLC}}_R = (\mathtt{Setup}^H,\allowbreak \mathtt{Prove}^H,\allowbreak \mathtt{Verify}^H,\allowbreak \mathtt{SimSetup},\allowbreak \mathtt{SimProve},\allowbreak \mathtt{Extract})$ for relation $R$ in the random oracle model has the \emph{non-interactive special simulation-soundness} property if for any security parameter $\lambda$, any random oracle $H$, any PPT adversary \adv, there exist some negligible function \negl such that $\Pr[\mathtt{Fail} \gets \mathsf{NIM}\text{-}\mathsf{SSS}^{H_*, \mathtt{Prog}}_{\adv, \Pi^{\mathtt{SLC}}_R} (1^\lambda)] \le \negl(\lambda)$.
76+
\end{definition}
77+
78+
For completeness, we also describe the security game $\mathsf{NIM}\text{-}\mathsf{SSS}^{H_*, \mathtt{Prog}}_{\adv, \Pi^{\mathtt{SLC}}_R} (1^\lambda)$ related to the non-interactive special simulation-soundness property of the NIZK protocol where $\mathcal{Q}_\adv$ are \adv's queries to the RO (details see~\cite{TCC:LysRos22}).
79+
80+
\input{games/nim-sss}

‎content/preliminaries/main.tex‎

Lines changed: 86 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,86 @@
1+
\section{Preliminaries}
2+
\label{sec:preliminaries}
3+
4+
\paragraph{UC basics.}
5+
%
6+
We provide our protocols and security proofs in Canetti's universal composition (UC) framework~\cite{JC:Canetti00}.
7+
%
8+
We discuss the main components of our real-world model (including the associated hybrids).
9+
10+
We assume that the reader is familiar with simulation-based security and has basic knowledge of the (G)UC framework.
11+
%
12+
We review all the aspects of the execution model that are needed for our protocols and proof, but omit some of the low-level details and refer the interested reader to relevant works wherever appropriate.
13+
14+
We now recall the mechanics of activations in UC.
15+
%
16+
In a UC protocol execution, an honest party (ITI) gets activated either by receiving an input from the environment, or by receiving a message from one of its hybrid functionalities (or from the adversary).
17+
%
18+
Any activation results in the activated ITI performing some computation on its view of the protocol and its local state, and ends with either the party sending a message to some of its hybrid functionalities, sending an output to the environment, or not sending any message at all.
19+
%
20+
In any of these cases, the party loses the activation.\footnote{In the latter
21+
case the activation goes to the environment by default.}
22+
%
23+
We denote the identities of parties by $\party_i$, i.e. $\party_i = (\pid_i,\sid_i)$, and call $\party_i$ a party for short.
24+
%
25+
The index $i$ is used to distinguish two identifiers, i.e., $\party_i \neq \party_j$, and otherwise carries no meaning.
26+
%
27+
We will assume a central adversary \adv who gets to corrupt miners and might use them to attempt to break the protocol's security.
28+
%
29+
As is common in (G)UC, the resources available to the parties are described as hybrid functionalities.
30+
%
31+
Our protocols are synchronous (G)UC protocols~\cite{C:BMTZ17}: parties have access to a (global) clock setup, denoted by \funcClock and can communicate over a network diffuse functionality \funcDiffuse (mode details on these functionalities are provided later).
32+
%
33+
We next sketch its main components:
34+
%
35+
All functionalities, protocols, and setups have a dynamic party set.
36+
%
37+
I.e., they all include special instructions allowing parties to register and deregister, and allow the adversary to learn the current set of registered parties.
38+
%
39+
Additionally, global setups allow any other setup (or functionality) to
40+
register and deregister with them\footnote{We note that the functionality can learn the code of the registering party (functionality) by considering the \emph{extended identifier} in~\cite{TCC:BCHTZ20}.} and also allow other setups to learn their set of registered parties.
41+
42+
\paragraph{Clock and diffusion functionality.}
43+
%
44+
Following the treatment in~\cite{C:BMTZ17}, we model the synchronous processors and bounded-delay network as \funcClock and \funcDiffuse respectively.
45+
%
46+
The global clock \funcClock maintains a round index for each session, and this index can only be forwarded when all registered honest parties (in this session) have finished their computation for this round.
47+
%
48+
The diffuse functionality \funcDiffuse captures \delay-bounded network --- i.e., when a message (either honest or adversarial) is reached by at least one honest party at round $r$, it is guaranteed to be delivered to all honest parties before round $r + \delay$.
49+
%
50+
A detailed description of these functionalities is presented in~\cref{sec:preliminaries-contd}.
51+
52+
\paragraph{Global random oracles.}
53+
%
54+
The hash function $H$ to generate PoW is modeled as a (global) random oracle \funcGRO; by convention, we use a wrapper functionalities \wrapper{\funcGRO} to restrict the adversarial and \emph{environmental} access to \funcGRO.
55+
%
56+
We assume honest majority in terms of the computational power to solve PoWs.
57+
%
58+
I.e., in every round the RO wrapper allows more accesses from the honest parties than the corrupted (and environmental) ones.
59+
%
60+
We also adopt a restricted programmable and observable global random oracle \funcGrpoRO \cite{EC:CDGLN18} to model a hash function $G$ that is different from the one used to generate PoW.
61+
%
62+
We discuss these two global random oracles in detail in~\cref{sec:preliminaries-contd}.
63+
64+
\paragraph{Non-interactive zero knowledge.}
65+
%
66+
For our construction we use a non-interactive, straight-line simulation extractable (NISLE) proof system that relies on \funcGrpoRO as the only setup assumption.
67+
%
68+
A protocol that satisfies such a security definition is provided in~\cite{TCC:LysRos22}.
69+
%
70+
We assume familiarity with the notion of simulation extractable NIZK, and refer to~\cref{sec:preliminaries-contd} for the formal definition.
71+
72+
\paragraph{Pseudorandom functions, one-way functions and hardcore bits.}
73+
%
74+
Let $F : \{0, 1\}^\ast \times \{0, 1\}^\ast \rightarrow \{0, 1\}^\ast$ be a keyed function.
75+
%
76+
$F$ is a pseudorandom function (PRF) if for all PPT distinguisher $D$ it holds that
77+
%
78+
\( | \Pr_{k \gets \{0, 1\}^n}[D^{F_k(\cdot)} = 1] - \Pr_{f \gets \mathcal{F}_n}[D^{f}(\cdot) = 1] | \le \negl(n). \)
79+
%
80+
A function $f : \{0, 1\}^* \rightarrow \{0, 1\}^*$ is a one-way function if there exists an efficient algorithm for evaluating $f$, and for all PPT adversary \adv, we have
81+
%
82+
\( \Pr_{x \gets \{0, 1\}^n}[\adv(f(x)) \in f\inv(f(x))] \le \negl(n). \)
83+
%
84+
A hardcore bit is a function $b : \{0, 1\}^\ast \rightarrow \{0, 1\}$ such that for all PPT adversary \adv, it holds that
85+
%
86+
\( \Pr_{x \gets \{0, 1\}^n}[\adv(f(x)) = b(x)]| \le \frac{1}{2} + \negl(n). \)

‎functionalities/diffuse.tex‎

Lines changed: 69 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,69 @@
1+
\begin{cccFunctionality}
2+
{\funcDiffuse}
3+
{diffuse}
4+
{The diffusion network.}
5+
6+
\newcommand*{\msgid}{\ensuremath{\mathsf{mid}}\xspace}
7+
\newcommand*{\vecM}{\ensuremath{\vec{M}}\xspace}
8+
9+
The functionality is parameterized by the network delay \delay.
10+
11+
\begin{minipage}{\linewidth}
12+
\begin{tabularx}{.9\textwidth}{c X}
13+
\toprule[.3mm]
14+
\textbf{State Variable}
15+
& \textbf{Description}
16+
\\ \midrule[.3mm]
17+
$\partyset \gets \emptyset$
18+
& The set of registered parties.
19+
\\ \midrule
20+
$\vecM \gets [] $
21+
& A dynamically updatable list of quadruples $(m, \msgid, D_{\msgid}, \party)$ where $D_{\msgid}$ denotes the fetch counter.
22+
\\ \bottomrule[.3mm]
23+
\end{tabularx}
24+
\addtocounter{table}{-1}
25+
\end{minipage}
26+
27+
\paragraph{Network capabilities:}
28+
%
29+
\begin{cccItemize}[nosep]
30+
\item Upon receiving $(\textsc{diffuse}, \sid, m)$ from some
31+
$\party_s \in \partyset$, where $\partyset = \{ \party_1, \ldots, \party_n \}$ denotes the current party set, do:
32+
%
33+
\begin{cccEnum}[nosep]
34+
\item Choose $n$ new unique message-IDs $\msgid_1, \ldots, \msgid_n$.
35+
\item Initialize $2n$ new variables $D_{\msgid_1} := D^{MAX}_{\msgid_1} \ldots := D_{\msgid_n} := D^{MAX}_{\msgid_n} := 1$ and a per message-delay $\delay_{\msgid_i} = \delay$ for $i \in [n]$.
36+
\item Set $\vecM := \vecM \concat (m, \msgid_1, D_{\msgid_1}, \party_1) \concat \ldots \concat (m, \msgid_n, D_{\msgid_n}, \party_n)$.
37+
\item Send $(\textsc{diffuse}, \sid, m, \party_s, (\party_1, \msgid_1), \ldots ,(\party_n, \msgid_n))$ to the adversary.
38+
\end{cccEnum}
39+
40+
\item Upon receiving $(\textsc{fetch}, \sid)$ from $\party \in \partyset$, or from \adv on behalf of a corrupted party \party:
41+
%
42+
\begin{cccEnum}[nosep]
43+
\item For all tuples $(m, \msgid, D_\msgid, \party) \in \vecM$, set $D_\msgid := D_\msgid - 1$.
44+
\item Let $\vecM^\party_0$ denote the subvector \vecM including all tuples of the form $(m, \msgid, D_\msgid, \party)$ with $D_\msgid \le 0$ (in the same order as they appear in \vecM).
45+
%
46+
Delete all entries in $\vecM^\party_0$ from \vecM and in case some $(m, \msgid, D_\msgid, \party)$ is in
47+
$\vecM^\party_0$, where \party is honest, set $\delay_{\msgid'} = \delay$ for any $(m, \msgid', D_{\msgid'}, (\cdot, \sid))$ in \vecM and replace this record by $(m, \msgid', \min \{ D_{\msgid'}, \delay \}, \party')$.
48+
\item Output $\vecM^\party_0$ to \party (if \party is corrupted, send $\vecM^\party_0$ to \adv).
49+
\end{cccEnum}
50+
\end{cccItemize}
51+
52+
\paragraph{Additional adversarial capabilities:}
53+
%
54+
\begin{cccItemize}[nosep]
55+
\item Upon receiving $(\textsc{diffuse}, \sid, m)$ from some corrupted $\party_s \in \partyset$ (or from \adv on behalf of $\party_s$ if corrupted),
56+
% do
57+
execute it the same way as an honest-sender diffuse, with the only difference that $\delay_{\msgid_i} = \infty$.
58+
59+
\item Upon receiving $(\textsc{delays}, \sid, (T_{\msgid_{i_1}}, \msgid_{i_1}), \ldots, (T_{\msgid_{i_\ell}}, \msgid_{i_\ell}))$ from the adversary do the following for each pair $(T_{\msgid_{i_j}}, \msgid_{i_j})$:
60+
%
61+
if $D^{MAX}_{\msgid_{i_j}} + T_{\msgid_{i_j}} \le \delay_{\msgid_{i_j}}$ and $\msgid_{i_j}$ is a message-ID of receiver $\party = (\cdot, \sid)$ registered in the current \vecM, set $D_{\msgid_{i_j}} := D_{\msgid_{i_j}} + T_{\msgid_{i_j}}$ and set $D^{MAX}_{\msgid_{i_j}} := D^{MAX}_{\msgid_{i_j}} + T_{\msgid_{i_j}}$; otherwise, ignore this pair.
62+
63+
\item Upon receiving $(\textsc{swap}, \sid, \msgid, \msgid')$ from the adversary, if \msgid and $\msgid'$ are message-IDs registered in the current \vecM, then swap the triples $(m, \msgid, D_\msgid, (\cdot, \sid))$ and $(m, \msgid', D_{\msgid'}, (\cdot, \sid))$ in \vecM.
64+
%
65+
Return $(\textsc{swap}, \sid)$ to the adversary.
66+
67+
\item Upon receiving $(\textsc{get-reg}, \sid)$ from \adv, return the response $(\textsc{get-reg}, \sid, \partyset)$ to \adv.
68+
\end{cccItemize}
69+
\end{cccFunctionality}

‎functionalities/global-clock.tex‎

Lines changed: 40 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,40 @@
1+
\begin{cccFunctionality}
2+
{\funcClock}
3+
{clock}
4+
{The global clock.}
5+
6+
This functionality maintains state variables as follows.
7+
8+
\begin{tabularx}{.9\textwidth}{c X}
9+
\toprule[.3mm]
10+
\textbf{State Variable}
11+
& \textbf{Description}
12+
\\ \midrule[.3mm]
13+
$\partyset \gets \emptyset$
14+
& The set of registered parties $\party = (\pid, \sid)$.
15+
\\ \midrule
16+
$F \gets \emptyset$
17+
& The set of registered functionalities (together with their session identifier).
18+
\\ \midrule
19+
$\tau_\sid \gets 0$
20+
& The clock variable for session \sid.
21+
\\ \midrule
22+
$d_\party \gets 0$
23+
& The clock-update variable for $\party = (\pid, \sid) \in \partyset$.
24+
\\ \midrule
25+
$d(\F, \sid) \gets 0$
26+
& The clock-update variable for $(\F, \sid) \in F$.
27+
\\ \bottomrule[.3mm]
28+
\end{tabularx}
29+
\addtocounter{table}{-1}
30+
31+
\begin{cccItemize}[noitemsep]
32+
\item Upon receiving $(\textsc{clock-update}, \sid_C)$ from some party $\party \in \partyset$ set $d_\party \gets 1$; execute \emph{Round-Update} and forward $(\textsc{clock-update}, \sid_C, \party)$ to \adv.
33+
34+
\item Upon receiving $(\textsc{clock-update}, \sid_C)$ from some functionality \F in a session \sid such that $(\F, \sid) \in F$ set $d(\F, \sid) \gets 1$, execute \emph{Round-Update} and return $(\textsc{clock-update},\allowbreak \sid_C, \F)$ to this instance of \F.
35+
36+
\item Upon receiving $(\textsc{clock-read}, \sid_C)$ from any participant (including the environment on behalf of a party, the adversary, or any ideal—shared or local—functionality) return $(\textsc{clock-read}, sid_C , \tau_{\sid})$ to the requestor (where \sid is the \sid of the calling instance).
37+
\end{cccItemize}
38+
39+
\emph{Procedure Round-Update:} For each session \sid do: If $d(\F, \sid) = 1$ for all $\F \in F$ and $d_\party = 1$ for all honest partyset $P = (\cdot, \sid) \in \partyset$, then set $\tau_\sid \gets \tau_\sid + 1$ and reset $d(\F, \sid) \gets 0$ and $d_\party \gets 0$ for all partyset $\party = (\cdot, \sid) \in \partyset$.
40+
\end{cccFunctionality}

0 commit comments

Comments
 (0)