mirror of
https://github.com/monero-project/research-lab.git
synced 2025-01-31 06:45:52 +00:00
Brandon Goodell
GitHub
commit
f80a0455c2
5 changed files with 197 additions and 113 deletions
Binary file not shown.
|
|
@ -85,7 +85,7 @@
|
|||
}
|
||||
|
||||
@article{scozzafava1993uniform,
|
||||
title={Uniform distribution and sum modulo m of independent random variables},
|
||||
title={Uniform distribution and sum modulo $m$ of independent random variables},
|
||||
author={Scozzafava, Paola},
|
||||
journal={Statistics \& probability letters},
|
||||
volume={18},
|
||||
|
|
@ -93,4 +93,35 @@
|
|||
pages={313--314},
|
||||
year={1993},
|
||||
publisher={Elsevier}
|
||||
}
|
||||
|
||||
@misc{maxwell2015borromean,
|
||||
title={Borromean ring signatures},
|
||||
author={Maxwell, Gregory and Poelstra, Andrew},
|
||||
year={2015}
|
||||
}
|
||||
|
||||
@article{bonehthreshold,
|
||||
title={Threshold Cryptosystems From Threshold Fully Homomorphic Encryption},
|
||||
author={Boneh, Dan and Gennaro, Rosario and Goldfeder, Steven and Jain, Aayush and Kim, Sam and Rasmussen, Peter MR and Sahai, Amit}
|
||||
}
|
||||
|
||||
@article{shamir1979share,
|
||||
title={How to share a secret},
|
||||
author={Shamir, Adi},
|
||||
journal={Communications of the ACM},
|
||||
volume={22},
|
||||
number={11},
|
||||
pages={612--613},
|
||||
year={1979},
|
||||
publisher={ACm}
|
||||
}
|
||||
|
||||
@incollection{shamir1981mental,
|
||||
title={Mental poker},
|
||||
author={Shamir, Adi and Rivest, Ronald L and Adleman, Leonard M},
|
||||
booktitle={The mathematical gardner},
|
||||
pages={37--43},
|
||||
year={1981},
|
||||
publisher={Springer}
|
||||
}
|
||||
|
|
@ -0,0 +1,30 @@
|
|||
@misc{cryptonote,
|
||||
title = {CryptoNote v2.0},
|
||||
author = {van Saberhagen, Nicolas},
|
||||
year = {2013}
|
||||
}
|
||||
|
||||
|
||||
@misc{van2013cryptonote,
|
||||
title={Cryptonote v 2. 0},
|
||||
author={van Saberhagen, Nicolas},
|
||||
year={2013}
|
||||
}
|
||||
|
||||
@misc{pr,
|
||||
title = {Subaddresses},
|
||||
author = {Monero project},
|
||||
howpublished = "\url{https://github.com/monero-project/monero/pull/2056}",
|
||||
note = {GitHub pull request \#2056}
|
||||
}
|
||||
|
||||
@article{uniform,
|
||||
title={Uniform distribution and sum modulo m of independent random variables},
|
||||
author={Scozzafava, Paola},
|
||||
journal={Statistics \& Probability Letters},
|
||||
volume={18},
|
||||
number={4},
|
||||
pages={313--314},
|
||||
year={1993},
|
||||
publisher={Elsevier}
|
||||
}
|
||||
|
|
@ -4,6 +4,7 @@
|
|||
\usepackage[top=1in,bottom=1in,right=1in,left=1in]{geometry}
|
||||
\usepackage{color}
|
||||
\usepackage{graphicx}
|
||||
\usepackage{hyperref}
|
||||
|
||||
\definecolor{bloo}{rgb}{0,0.2,0.4}
|
||||
\renewcommand*{\thefootnote}{\fnsymbol{footnote}}
|
||||
|
|
|
|||
|
|
@ -19,37 +19,23 @@
|
|||
|
||||
\begin{document}
|
||||
|
||||
% Title area
|
||||
%\hfill\includegraphics[width=100px]{logo.png}
|
||||
%\newline
|
||||
%\noindent\colorbox{bloo}{\parbox{\textwidth}{{\sffamily\color{white}RESEARCH BULLETIN \hfill MRL-9999a}}}
|
||||
%\vskip 10pt
|
||||
%\noindent{\Large Ring Threshold Multisignature Schemes and Security Models}
|
||||
%\vskip 5pt
|
||||
%\noindent{Brandon Goodell\footnote{\texttt{surae.noether@protonmail.com}} and Sarang Noether}
|
||||
%\newline
|
||||
%\noindent{Monero Research Lab}
|
||||
%\newline
|
||||
%\noindent{\today}
|
||||
|
||||
%\begin{frontmatter}
|
||||
%\begin{abstractbox}
|
||||
\begin{abstract}
|
||||
This research bulletin extends \cite{noether2016ring} by constructing a $t$-of-$n$ threshold multi-layered linkable spontaneous anonymous group signature scheme ($t$-of-$n$ MLSAG) in the same style as the LSAG schemes put forth by \cite{liu2004linkable}. %We present security models for this scheme, present security proofs in those models, describe an implementation, and explain some use-cases for the scheme in cryptocurrencies.
|
||||
\end{abstract}
|
||||
%\end{abstractbox}
|
||||
%\end{frontmatter}
|
||||
|
||||
|
||||
\section{Introduction and Background}
|
||||
|
||||
Ring signatures can play a critical role in promoting user anonymity (or at least user ambiguity) during message authentication. A one-time signature scheme inserts a barrier between user key pairs and one-time signature key pairs. Due to this utility, one-time ring signature schemes enjoy application in many cryptocurrency protocols. Multisignatures play a critical role in off-chain transactions for cryptocurrencies (e.g.\ the Bitcoin Lightning Network) and for message authentication in general (e.g.\ multi-factor authentication). A $t$-of-$N$ threshold multisignature scheme specifies sets containing $N$ public keys and thresholds $t$ such that any subset with at least $t$ elements may collaborate to fashion a signature. A usual digital signature scheme is a $1$-of-$1$ multisignature scheme, so we can regard all keys as shared public keys (just perhaps with a coalition of only one member). It is therefore natural to extend the notion of ring signatures to ring threshold multisignatures for implementation in cryptocurrencies to enjoy signer-ambiguous multisignatures.
|
||||
Collaboration to construct, compute, share, and leak a secret is a central goal in the construction of cryptographic systems. Although the idea of constructing a shared secret has a very long history, modern secret sharing through threshold cryptosystems found its most successful footing in \cite{shamir1979share}. These and related ideas (as in \cite{shamir1981mental}) formed the historical foundation of secure multi-party computation, threshold encryption, and threshold authentication. For example, threshold multisignatures play a critical role in multi-factor message authentication in general and off-chain transactions for cryptocurrencies in particular, e.g.\ the Bitcoin Lightning Network. For a more modern treatment of threshold cryptosystems, see \cite{bonehthreshold}.
|
||||
|
||||
A multisignature scheme is a $t$-of-$N$ \textit{ring threshold multisignature} (RTM) scheme if any set of $N$ keys may be specified as a coalition of signers and assigned a shared public key $X_{\texttt{shared}}$ such that any $t$ coalition members may collaborate to fashion a ring signature. The ring of signatories $R$ contains the key $X_{\texttt{shared}}$, but an adversary cannot determine which element of $R$ computed the signature.
|
||||
Ring signatures are digital signatures that are verifiably signed by one of possibly several public keys (\textit{ring members}), and can play a critical role in promoting signer during message authentication. It is therefore natural to apply the notion of threshold cryptosystems to ring signatures for implementation in cryptocurrencies, resulting in signer-ambiguous threshold multisignatures.
|
||||
|
||||
If the number of users cooperating in the construction of a signature is not secret, naive multisignature schemes can be constructed from any signature scheme (ring signature or otherwise) by simply requiring each participating user to present a separate signature. More sophisticated implementations combine these together using boolean AND circuits as in the Borromean ring set-up described in \cite{} for efficiency reasons.
|
||||
A $t$-of-$N$ threshold multisignature scheme specifies sets containing $N$ public keys and thresholds $t$ such that any subset with at least $t$ elements may collaborate to fashion a signature. A \textit{ring threshold multisignature} (RTM) scheme allows any set of $N$ keys to collaborate as a coalition of signers with threshold $t$. The coalition is assigned a shared public key $X_{\texttt{shared}}$ such that any $t$ coalition members may collaborate to fashion a ring signature with $X_{\texttt{shared}}$. The ring of signatories $\mathcal{Q}$ contains the key $X_{\texttt{shared}}$, but an adversary cannot determine which element of $Q$ computed the signature. This may be made into a \textit{linkable} signature scheme using key images, and this may be made into a \textit{one-time} signature scheme by inserting a one-time key exchange step between signing and the construction of $X_{\texttt{shared}}$. A one-time signature scheme inserts a barrier between user key pairs and one-time signature key pairs. Due to this utility, one-time ring signature schemes enjoy application in many cryptocurrency protocols.
|
||||
|
||||
If a user does not desire to reveal to an adversary how many devices were used for some multi-factor authentication, it should be difficult for an adversary to determine the size of a coalition behind some shared public key. This property should be satisfied even if the adversary can persuade the party (or parties) controlling the shared public key to sign arbitrary messages chosen by the adversary. We introduce the security definition of \textit{coalition-indistinguishable} multisignature schemes against adaptive chosen message attacks: given a shared $t$-of-$N$ public key $X_{\texttt{shared}}$, an adversary should be unable to guess any information about $t$ or $N$. %This property cannot be satisfied if the adversary has corrupted any public key in the coalition. If some coalition member for $X$, say $X^{\prime}$, is a shared $t^{\prime}$-of-$N^{\prime}$ public key, this means that if the adversary has corrupted $t^{\prime}$ or more members of the coalition for $X^{\prime}$, then coalition-indistinguishability is impossible. Thus we investigate the notion of \textit{subthreshold corruption oracle access}.
|
||||
A usual digital signature scheme is a $1$-of-$1$ multisignature scheme, so we can regard all keys as shared public keys (just perhaps with a coalition of only one member). A $1$-of-$N$ multisignature scheme can be trivially accomplished by handing out the same private key to each coalition member.
|
||||
|
||||
If the number of users cooperating in the construction of a signature is not secret, naive multisignature schemes can be constructed from any signature scheme (ring signature or otherwise) by simply requiring each participating user to present a separate signature. These signatures can be combined into a list to obtain signature sizes that vary according to the number of signers, or can be combined in more sophisticated ways that are more private (see \cite{bonehthreshold}). If a user does not desire to reveal to an adversary how many devices were used for some multi-factor authentication, it should be difficult for an adversary to determine the size of a coalition behind some shared public key. We investigate some security definitions for a one-time linkable ring threshold multisignature (OT-LRTM) scheme.
|
||||
|
||||
%This property cannot be satisfied if the adversary has corrupted any public key in the coalition. If some coalition member for $X$, say $X^{\prime}$, is a shared $t^{\prime}$-of-$N^{\prime}$ public key, this means that if the adversary has corrupted $t^{\prime}$ or more members of the coalition for $X^{\prime}$, then coalition-indistinguishability is impossible. Thus we investigate the notion of \textit{subthreshold corruption oracle access}.
|
||||
|
||||
%Moreover, for multifactor authentication purposes, $(N-1)$-of-$N$ and $N$-of-$N$ schemes are of particular interest. Due to this, we consider only $t$-of-$N$ threshold ring signatures with $N-1 \leq t \leq N$, with $t > 1$, and with $N > 1$.
|
||||
|
||||
|
|
@ -57,74 +43,79 @@ If a user does not desire to reveal to an adversary how many devices were used f
|
|||
|
||||
\subsection{Our Contribution}
|
||||
|
||||
We consider a formal definition of one-time linkable ring threshold multisignature (OT-LRTM) schemes. We investigate modifications to security definitions that take threshold behaviors into account and a new security model. We describe a modified implementation of $t$-of-$N$ linkable ring threshold multisignature (under the restriction $N-1 \leq t \leq N$) first described by previous MRL contributors Shen Noether in \cite{noether2016ring} and implemented for use in Monero by contributor \texttt{Luigi}, and we prove that this implementation satisfies our security definitions.
|
||||
|
||||
We consider a formal definition of one-time linkable ring threshold multisignature (OT-LRTM) schemes. We introduce the definition of \textit{coalition-indistinguishable keys}, \textit{signer ambiguity}, and \textit{existential unforgeability} in these schemes. We describe a modified implementation of $t$-of-$N$ linkable ring threshold multisignature (under the restriction $N-1 \leq t \leq N$ with $2
|
||||
\leq t$ and $2 \leq N$) first described by previous Monero Research Lab (MRL) contributors Shen Noether in \cite{noether2016ring} and implemented for use in Monero by contributor \texttt{Luigi}. We prove that this implementation satisfies our security definitions. Lastly, we remark on some recent advancements in thresholdizing cryptoschemes from \cite{bonehthreshold} using different security definitions.
|
||||
|
||||
|
||||
\subsection{Notation and Prerequisites}
|
||||
|
||||
We let $\mathbb{G}$ be a group with prime order $\mathfrak{q}$ and we let $G$ denote a commonly known point with order $\mathfrak{q}$. Denote the user and transaction key spaces, respectively, as $\mathcal{K}_{\texttt{user}}, \mathcal{K}_{\texttt{txn}}$. In implementations involving cryptocurrencies, there exists a function $\texttt{dest}:\mathcal{K}_{\texttt{txn}} \to \mathcal{K}_{\texttt{user}}$ describing the user key pair to whom a certain transaction key pair is addressed. For any transaction key pair $(q,Q) \in \mathcal{K}_{\texttt{txn}}$, we say $\texttt{dest}(q,Q)$ is the \textit{destination} user key pair for $(q,Q)$. We sometimes write $Q$ as $Q_X$ to emphasize the destination user key $X$ associated with the transaction key $Q$.
|
||||
We let $\mathbb{G}$ be a group with prime order $\mathfrak{q}$ and we let $G \in \mathbb{G}$ denote a commonly-known point with order $\mathfrak{q}$. Let $H_p$ and $H_s$ be secure cryptographic hash-to-point and hash-to-scalar functions. Denote the user and transaction key spaces, respectively, as $\mathcal{K}_{\texttt{user}}, \mathcal{K}_{\texttt{txn}}$. In implementations involving cryptocurrencies, there exists a function $\texttt{dest}:\mathcal{K}_{\texttt{txn}} \to \mathcal{K}_{\texttt{user}}$ describing the user key pair to whom a certain transaction key pair is addressed. For any transaction key pair $(q,Q) \in \mathcal{K}_{\texttt{txn}}$, we say $\texttt{dest}(q,Q)$ is the \textit{destination} user key pair for $(q,Q)$. %We sometimes write $Q$ as $Q_X$ to emphasize the destination user key $X$ associated with the transaction key $Q$.
|
||||
%We denote the message space $\mathcal{M}=\left\{0,1\right\}^*$. We let $\mathbb{G}$ be an additive group with prime order $q$ an an arbitrary generator $G$. We denote $H_{\mathcal{X},\mathcal{Y}}(-)$ as a cryptographic hash function from the space $\mathcal{X}$ to $\mathcal{Y}$. For example $H_{\mathbb{G},\mathbb{Z}_q}(-)$ is a cryptographic point-to-scalar function. We assume that any two hash functions $H_{\mathcal{X},\mathcal{Y}}(-)$ and $H_{\mathcal{X}^{\prime},\mathcal{Y}^{\prime}}(-)$ are statistically independent.
|
||||
|
||||
|
||||
\section{MLSAG and Straightforward Threshold Set-ups}
|
||||
|
||||
|
||||
We briefly describe LSAG ring signatures in the sense of \cite{liu2004linkable} and their MLSAG variant used in Monero, and then a straightforward implementation of an LRTM scheme.
|
||||
We briefly describe LSAG ring signatures in the sense of \cite{liu2004linkable} and their MLSAG variant as used in Monero, and then a straightforward implementation of an LRTM scheme (which is one-time if the transaction keys are one-time).
|
||||
|
||||
\subsection{MLSAGs}
|
||||
|
||||
A user with user key pair $(y,Y)$ wishes to spend an old transaction output with private-public transaction key pair $(q,Q) \in \mathcal{K}_{\texttt{txn}}$ such that $\texttt{dest}(q,Q) = (y,Y)$. The user constructs an appropriate message $M$, a destination user key $X$, computes the key image $J = qH_p(Q)$, and selects a ring of public transaction keys $R=\left\{Q_1, \ldots Q_L\right\}$ such that, for a secret distinguished index $k$, $Q_{k}=Q$. For each $i=1,\ldots,L$, the signer computes an elliptic curve point from the $i^{th}$ ring member public key as $H_i := H_{p}(Q_i)$. The signer selects a random secret scalar $u$, computes an initial temporary pair of points $uG$ and $uH_{k}$, and computes an initial commitment $c_{k+1} := H_{p}(M,uG, uH_k)$.
|
||||
A user with user key pair $(y,Y)$ wishes to spend an old transaction output with private-public transaction key pair $(q,Q) \in \mathcal{K}_{\texttt{txn}}$ such that $\texttt{dest}(q,Q) = (y,Y)$. With a destination user key $X$, the user computes a new transaction public key $Q*$, constructs an appropriate message $M$, computes the key image $J = qH_p(Q)$, and selects a ring of public transaction keys $\mathcal{Q}=\left\{Q_1, \ldots Q_L\right\}$ such that, for a secret distinguished index $k$, $Q_{k}=Q$. For each $i=1,\ldots,L$, the signer computes an elliptic curve point from the $i^{th}$ ring member public key as $H_i := H_{p}(Q_i)$. The signer computes $M^* = (M, J, Q^*, \mathcal{Q})$.
|
||||
|
||||
The signer sequentially proceeds through indices $i=k+1, k+2, \ldots, n, 1, 2, \ldots, k-1$ in the following way. The signer selects a random scalar $s_i$, computes the next temporary pair of points $s_iG + c_i Q_i$ and $s_i H_i + c_i J$, and computes the next commitment $c_{i+1}:=H_{p}(m,s_i G + c_i Q_i, s_i H_i + c_i J)$. The signer continues proceeding through the set of keys until commitments $c_i$ have been computed for each $i=1, \ldots, L$. The signer then computes $s_{k}:=u - c_{k}q_{k}$ and publishes the signature $\sigma=(c_1, s_1, \ldots, s_n)$ and the key image $J$ in a signature-tag pair $(\sigma, J)$.
|
||||
The signer selects a random secret scalar $u$, computes an initial temporary pair of points $uG$ and $uH_{k}$, and computes an initial commitment $c_{k+1} := H_{s}(M^*,uG, uH_k)$. The signer sequentially proceeds through indices $i=k+1, k+2, \ldots, L, 1, 2, \ldots, k-1$ by selecting a random scalar $s_i$, computing the next pair of points $s_iG + c_i Q_i$ and $s_i H_i + c_i J$, and computes the next commitment $c_{i+1}:=H_{s}(M^*,s_i G + c_i Q_i, s_i H_i + c_i J)$. The signer continues proceeding through the set of keys until commitments $c_i$ have been computed for each $i=1, \ldots, L$. The signer then computes $s_{k}:=u - c_{k}q_{k}$.
|
||||
|
||||
A signature-tag pair $(\sigma^*, J^*)$ on $m$ can be verified to have been generated by at least one ring member in the following way: for each $i=1,2,\ldots, L$, the verifier computes $z_{i} = s_i^* G + c_i^* Q_i$ and $z_{i}^{\prime} = s_i^* H_i + c_i^* J^*$ and uses these to compute the $(i+1)^{th}$ commitment $c_{i+1} = H_{p}(m, z_i, z^{\prime}_i)$. After computing $c_2, c_3, \ldots, c_L, c_1$, the verifier approves of the signature if and only if $c_1 = c_1^*$. A verifier can check against double spends by comparing the key images of two signature-tag pairs.
|
||||
Now $\sigma=(c_1, s_1, \ldots, s_L)$ is the signature on $M^*$. A verifier checks this $M^*$ signed by at least one member of $\mathcal{Q}$ in the following way. Given a message $M^*$ and signature $\sigma$, the verifier parses $M^* = (M,J,Q^*,\mathcal{Q})$ and $\sigma = (c_1, s_1, \ldots, s_L)$. For each $i=1,2,\ldots, L$, the verifier computes $z_{i} = s_i^* G + c_i^* Q_i$ and $z_{i}^{\prime} = s_i^* H_i + c_i^* J^*$ and uses these to compute the $(i+1)^{th}$ commitment $c_{i+1} = H_{s}(M^*, z_i, z^{\prime}_i)$. After computing $c_2, c_3, \ldots, c_L, c_1$, the verifier approves of the signature if and only if $c_1 = c_1^*$. A verifier can check against double spends by comparing the key images of two signature-tag pairs.
|
||||
|
||||
\begin{disc}
|
||||
The MLSAG generalization, where transaction keys are represented by vectors, is straightforward. With transaction keys $\underline{q}=(q_1,\ldots,q_w)$, each component of $\underline{q}$ is used to generate a temporary pair of points starting with $u_jG$, $u_j H_k$ and then $s_{j,i} G + c_{i} Q_{j,i}$, $s_{j,i} H_{j,i} + c_{i} J$, providing the associated commitments
|
||||
\[c_{i+1}:=H_{p}\left(m,\left\{(s_{j,i} G + c_i Q_{j,i}, s_{j,i} H_{j,i} + c_i J)\right\}_{j=1}^{w}\right).\]
|
||||
\[c_{i+1}:=H_{s}\left(M^*,\left\{(s_{j,i} G + c_i Q_{j,i}, s_{j,i} H_{j,i} + c_i J)\right\}_{j=1}^{w}\right).\]
|
||||
\end{disc}
|
||||
|
||||
|
||||
\begin{disc}
|
||||
Note that user keys are not used above except as a destination for the transaction key. Anyone with a destination public user key in mind and knowledge of a transaction private key may fashion a signature like the one above. In the reference CryptoNote protocol, the private transaction key $q$ associated to some public transaction key $Q$ is only feasibly computable by a user who knows the private destination user key in $\texttt{dest}(q,Q)$ or by an adversary who can solve the discrete logarithm problem.
|
||||
Note that user keys are not used above except as a destination for the transaction key. Anyone with a destination public user key in mind and knowledge of a transaction private key may fashion a signature like the one above. In the reference CryptoNote protocol \cite{van2013cryptonote}, the private transaction key $q$ associated to some public transaction key $Q$ is only feasibly computable by a user who knows the private destination user key in $\texttt{dest}(q,Q)$ or by an adversary who can solve the discrete logarithm problem.
|
||||
\end{disc}
|
||||
|
||||
\subsection{Extending to Threshold Signatures} \label{naiveImplement}
|
||||
|
||||
Note that a $1$-of-$N$ threshold signature scheme may be accomplished by simply handing out an identical set of keys to $N$ individuals: whoever decides to use them first will be able to fashion a signature. We consider this a degenerate case. On the other hand, a $1$-of-$1$ signature scheme is a usual signature scheme, as we mentioned.
|
||||
%Note that a $1$-of-$N$ threshold signature scheme may be accomplished by simply handing out an identical set of keys to $N$ individuals: whoever decides to use them first will be able to fashion a signature. We consider this a degenerate case. On the other hand, a $1$-of-$1$ signature scheme is a usual signature scheme, as we mentioned. So we only consider $t$-of-$N$ signatures with $2 \leq t \leq N$.
|
||||
|
||||
Generally, we wish to allow a coalition of (distinct) public user keys $C=\left\{X_{1}, X_{2}, \ldots, X_{N}\right\} \subseteq \mathcal{K}_{\texttt{user}}$ (where each $X_i = x_iG$) to collaboratively fashion a shared public user key $X_{\texttt{shared}}$ such that, for any transaction key pair $(q,Q) \in \mathcal{K}_{\texttt{txn}}$ such that $\texttt{dest}(q,Q) = X_{\texttt{shared}}$, any subset of at least $t$ of the users in $C$ can collaborate to fashion a signature on a message $M$ corresponding to public transaction key $Q$. Certainly we wish that no member of $C$ reveal their own private user key $x_i$, but moreover we wish that coalition members cannot feasibly learn the private transaction key $q$.
|
||||
|
||||
In the $N$-of-$N$ case, we may use CryptoNote-styled user and transaction keys to see an example implementation. For this example, we assume user private-public key pairs $(x,X)$ take the form $x=(a,b)$ for some scalars $a$, $b$ and $X=(A,B)$ where $A=aG$ and $B=bG$ for some common point $G$. The private-public transaction key pair $(q,Q)$ takes the form $Q=(S,P)$, $q=(s,p)$ where $s$ is a scalar, $S=sG$, $p=H_s(aR)+b$, and $P=pG$. Given message $M$, a coalition of user keys $C$, the coalition members compute their shared public key as $X_{\texttt{shared}} := \sum_{j=1}^{N} X_j$, which is published. Assume $(q,Q)=((s,p),(S,P))$ is a transaction key pair such that $\texttt{dest}(q,Q) = X_{\texttt{shared}}$.
|
||||
In the $N$-of-$N$ case, we may use CryptoNote-styled user and transaction keys to see an example implementation. For this example, we assume user private-public key pairs $(x,X)$ take the form $x=(a,b)$ for some scalars $a$, $b$ and $X=(A,B)$ where $A=aG$ and $B=bG$. The private-public transaction key pair $(q,Q)$ takes the form $Q=(S,P)$, $q=(s,p)$ where $s$ is a scalar, $S=sG$, $p=H_s(aS)+b$, and $P=pG$\footnote{In the CryptoNote whitepaper, the private key $p$ was denoted $x$, the random scalar $s$ wa denoted $r$, and the random point $S=sG$ was denoted $R=rG$. The point $S=sG$ (originally denoted $R$) in the original CryptoNote whitepaper was the \textit{public transaction key}, the value $P$ was the \textit{public output key}. This allowed for many outputs (each with their own signature) to have a common transaction output key. However, in MLSAG, we only use one output per signature anyway, so the value in distinguishing between $S$ as a transaction key and $P$ as an output key is diminished.}.
|
||||
|
||||
The coalition $C$ selects a ring of public transaction keys $\mathcal{R} = \left\{Q_1, Q_2, \ldots, Q_L\right\}$ such that $Q = Q_{k}$ for some secret index $k$. For each $j=1, \ldots, N$, the $j^{th}$ coalition member in $C$ computes a partial key image $J_j = (H_s(a_j S) + b_j)\cdot H_p(Q)$, picks a random secret scalar $u_j$, and computes $H_i = H_{p}(Q_i)$ for each $Q_i \in R$. The coalition $C$ computes the key image $J = \sum_j J_j$, the random points $u_{k} G = \sum_j u_{j} G$, and $u_{k} H_{k}= \sum_j u_{j} H_{k}$. The coalition $C$ decides upon random values $s_{k+1}, \ldots, s_{L}, s_1, \ldots, s_{k-1}$. Using these, any member in $C$ may compute the commitments
|
||||
Given a message $M$, the coalition of user keys $C$ compute their shared public key as $X_{\texttt{shared}} := (\sum_i A_i, \sum_i B_i)$, which is published. The coalition members secretly compute and share $a^*=\sum_i a_i$ and share this secret view key among themselves. With a destination user key $X$, the coalition computes a new transaction public key $Q^*$. Assume $(q,Q)=((s,p),(S,P))$ is a transaction key pair such that $\texttt{dest}(q,Q) = X_{\texttt{shared}}$. The coalition $C$ selects a ring of public transaction keys $\mathcal{Q} = \left\{Q_1, Q_2, \ldots, Q_L\right\}$ such that $Q = Q_{k}$ for some secret index $k$. For each $j=1, \ldots, N$, the $j^{th}$ coalition member in $C$ computes a partial key image $J_j = b_j H_p(Q)$, picks a random secret scalar $u_j$, and computes $H_i = H_{p}(Q_i)$ for each $Q_i \in R$. The coalition $C$ computes the key image $J = H_s(a^* S) + \sum_j J_j$. The coalition constructs an appropriate message $M^*=(M,J,Q^*,\mathcal{Q})$.
|
||||
|
||||
The coalition computes the points $u_{k} G = \sum_j u_{j} G$ and $u_{k} H_{k}= \sum_j u_{j} H_{k}$. The coalition $C$ decides upon random values $s_{k+1}, \ldots, s_{L}, s_1, \ldots, s_{k-1}$. Any member in $C$ may compute the commitments
|
||||
\begin{align*}
|
||||
c_{k+1} :=& H_{p}(m, u_k G, u_k H_k) \text{ and}\\
|
||||
c_{i+1} :=& H_{p}(m, s_{i} G + c_i P_i, s_{i} H_i + c_i J)\text{ for }i=k+1, \ldots, k-1.
|
||||
c_{k+1} :=& H_{s}(M^*, u_k G, u_k H_k) \text{ and}\\
|
||||
c_{i+1} :=& H_{s}(M^*, s_{i} G + c_i Q_i, s_{i} H_i + c_i J)\text{ for }i=k+1, \ldots, k-1.
|
||||
\end{align*}
|
||||
All coalition members then use $c_k$ to compute their personal $s_{k,j} = u_j - c_{k} (H_s(a_j S) + b_j)$. The signers share their $s_{k,j}$ with the other signers. Any threshold member may then compute the value $s_{k} = \sum_j s_{k,j}$ and publish the signature-tag pair $(\sigma, J)$ where $\sigma = (c_1, s_1, \ldots, s_L)$ as usual. Any user may verify this signature corresponds to the $N$-of-$N$ shared public key $X_{\texttt{shared}}$ using the same method as above.
|
||||
All coalition members then use $c_k$ to compute their personal $s_{k,j} = u_j - c_{k} b_j$. The signers share their $s_{k,j}$ with the other signers. Any threshold member may then compute the value $s_{k} = (\sum_j s_{k,j}) - c_k H_s(a^* S)$ and publishes as before. Any user may verify this signature corresponds to the $N$-of-$N$ shared public key $X_{\texttt{shared}}$ using the same method as above.
|
||||
|
||||
This set-up extends naturally to an $(N-1)$-of-$N$ set-up. As before, a set of $N$ public keys $\left\{X_{1}, X_{2}, \ldots, X_{N}\right\}$ form a coalition. Each pair of users has a shared secret scalar $z_{i,j} = H_{s}(x_i X_j)$ with associated point $Z_{i,j} = z_{i,j}G$. There are $\frac{N(N-1)}{2}$ such pairs; if any $N-1$ members get together, all of the associated shared secrets are known. Hence, we may simply instantiate the $(N-1)$-of-$N$ threshold as an $N^*$-of-$N^*$ set-up with $N^* = \frac{N(N-1)}{2}$. All values $Z_{i,j}$ are necessary to compute the shared public user key $Z_{\texttt{shared}}$, and all values of $z_{i,j}$ are necessary to fashion a signature with a public transaction key $Q$ with $\texttt{dest}(Q)=Z_{\texttt{shared}}$.
|
||||
|
||||
This implementation satisfies our immediate two properties: members in $C$ do not learn the private transaction key $q=\sum_j H_s(a_j S) + b_j$ and do not reveal their own private keys. Assuming at least one contributing user key in $C$ was honestly generated from a uniform random scalar, an adversary who has learned a public threshold address cannot determine the number of summands contributing to it, let alone determine the summands.
|
||||
|
||||
This set-up extends naturally to an $(N-1)$-of-$N$ set-up. As before, a set of $N$ public keys $\left\{X_{1}, X_{2}, \ldots, X_{N}\right\}$ form a coalition. Each pair of users has a shared secret scalar $z_{i,j} = H_{s}(x_i X_j)$ with associated point $Z_{ij} = z_{i,j}G$. There are $\frac{N(N-1)}{2}$ such pairs; if any $N-1$ members get together, all of the associated shared secrets are known. Hence, we may simply instantiate the $(N-1)$-of-$N$ threshold as an $N^*$-of-$N^*$ set-up with $N^* = \frac{N(N-1)}{2}$. All values $Z_{i,j}$ are necessary to compute the shared public user key, $Z_{\texttt{shared}}$ and all values of $z_{i,j}$ are necessary to fashion a signature with a public transaction key $Q$ with $\texttt{dest}(Q)=Z_{\texttt{shared}}$.
|
||||
\begin{disc}
|
||||
Note that members in $C$ do not directly learn the private transaction key $q=H_s(a^* S)+\sum_j b_j$ and do not directly reveal their own private \textit{spend} keys $b_j$ (although they collaborate to compute their shared private view key $a^*$. Assuming at least one contributing user key in $C$ was honestly generated from a uniform random scalar, an adversary who has learned a public threshold address cannot determine the number of summands contributing to it, let alone determine the summands. \end{disc}
|
||||
|
||||
%Coalition members certainly do not want to reveal their secret keys during participation, but dually, coalitions may not want the fact that an address has been collaboratively fashioned to be publicized. We should prefer, then, that implementations produce keys and signatures that are indistinguishable by an adversary from a usual signature scheme. We discuss this in more detail later.
|
||||
\begin{disc}\label{remark:recursion}
|
||||
Note that the above extension works for coalitions containing $t$-of-$N$ keys also. For example, when the $j^{th}$ coalition member computes the partial key image $J_j$, if this coalition member is some sub-coalition, then each member of the sub-coalition can compute their own partial key image $J_{j,k}$ and the sub-coalition can report the sum $J_j = \sum_k J_{j,k}$. In this manner, signatures involving nested coalitions may be executed recursively. We elaborate on this in Section \ref{sec:otlrtm}.
|
||||
Note that the same basic extension works for coalitions containing coalitions also: each time a member of a coalition must make a decision in a signing protocol, the coalition may simply compute a sum. For example, when the $j^{th}$ coalition member computes the partial key image $J_j$, if this coalition member is some sub-coalition, then each member of the sub-coalition can compute their own partial key image $J_{j,k}$ and the sub-coalition can report the sum $J_j = \sum_k J_{j,k}$. In this manner, signatures involving nested coalitions may be executed recursively. We elaborate on this in Section \ref{sec:otlrtm}.
|
||||
\end{disc}
|
||||
|
||||
\begin{disc}\label{hashed-keys}
|
||||
Note that an adversary with knowledge of some set of public keys can compute the sums of all subsets to brute-force test whether a certain user key $X$ is a threshold key. Using hash functions and encrypt-then-authenticate communication, we may resolve the brute force problem.
|
||||
Note that an adversary with knowledge of some set of public keys can compute the sums of all subsets to brute-force test whether a certain user key $X$ is a threshold key. Moreover, if the computation of sums is done inappropriately, the summands may be accidentally revealed. Using hash functions and encrypt-then-authenticate communication, we may resolve these problems.
|
||||
|
||||
Consider modifying the $N$-of-$N$ implementation by having coalition members select secret scalars $\mu_j$ associated with the threshold $t$ and coalition $C$, e.g.:
|
||||
\[\mu_j = H_s(\text{``multisig constant for escrow at local coffee shop''}, \texttt{secret salt})\]
|
||||
Now merely require that participating members not use their private user keys in the construction of their shared user key pair, but instead the $i^{th}$ coalition member selects a constant $\mu_i$ associated with their coalition and instead uses $x^*_i = H(x_i, \mu_i)$ as their private key (or in the $(N-1)$-of-$N$ case, computing $z^*_{i,j} = H_s(x_i^* X_j^*)$ instead of $z_{i,j} = H_s(x_i X_j)$ and communicating the points $Z^*_{i,j}$ to the coalition).
|
||||
Now merely require that participating members not use their private user keys in the construction of their shared user key pair, but instead the $i^{th}$ coalition member selects a constant $\mu_i$ associated with their coalition and instead uses $x^*_i = H(x_i, \mu_i)$ as their private key (or in the $(N-1)$-of-$N$ case, computing $z^*_{i,j} = H_s(x_i^* X_j^*)$ instead of $z_{i,j} = H_s(x_i X_j)$ and communicating the points $Z^*_{i,j}$ to the coalition). In the case of CryptoNote keys of the form $((a,b), (A,B))$, select constants $\mu_j, \gamma_j$ and set $a^* = H_s(a, \mu_j)$, $b^*=H_s(b,\gamma_j)$.
|
||||
|
||||
With this modification, an adversary cannot use strictly public information to determine if a certain key is a threshold key or not. The possibility remains that the adversary may overhear the associated public points $X^*_i$ (or $Z^*_{i,j}$) being communicated within the coalition, allowing the adversary to fall back on the brute force approach again. Hence, the points $X^*_i$ (or $Z^*_{i,j}$) should be communicated with a secure encrypt-then-authenticate scheme. Note that either step alone (hashing, then encrypt-then-authenticating) is insufficient to prevent the adversary from using brute force.
|
||||
With this modification, an adversary cannot use strictly public information to determine if a certain key is a threshold key or not. The possibility remains that the adversary may overhear the associated public points $X^*_i$ (or $Z^*_{i,j}$) being communicated within the coalition, allowing the adversary to fall back on the brute force approach again. Hence, the points $X^*_i$ (or $Z^*_{i,j}$) should be communicated with a secure encrypt-then-authenticate scheme. Note that either step alone (hashing, then encrypt-then-authenticating) is insufficient to prevent the adversary from using brute force. Also note that the above does not take into account the possibility of malicious coalition members.
|
||||
\end{disc}
|
||||
|
||||
|
||||
|
||||
\section{Security Models}
|
||||
|
||||
%In this section we present definitions we use later on. Any signature scheme requires unforgeability. Moreover, a ring signature scheme requires signature ambiguity. In a threshold multisignature scheme, coalitions of users collaborate to generate new threshold keys from sets of old keys and to generate signatures on messages using those threshold keys. A linkable signature
|
||||
|
|
@ -134,7 +125,7 @@ With this modification, an adversary cannot use strictly public information to d
|
|||
We begin by defining a one-time linkable ring threshold multisignature (OT-LRTM) scheme. A central idea to our security models is that a coalition of user keys may be merged into a new user key, which may then be again merged with other user keys.
|
||||
|
||||
|
||||
\begin{defn}{[One-Time Linkable Ring Threshold Multisignature Scheme]}\label{OT-LRTM} A one-time linkable ring threshold multisignature scheme is a set of PPT algorithms, (\texttt{UserKeyGen}, \texttt{TxnKeyGen}, \texttt{Merge},\texttt{Sign},\texttt{Verify}, \texttt{Link}) that, respectively, generates usual private-public keypairs for users, generates public transaction keys, merges user keys into new shared user keys, fashions signatures on messages given a ring of public transaction keys, verifies signatures, and links signatures. Formally:
|
||||
\begin{defn}{[One-Time Linkable Ring Threshold Multisignature Scheme]}\label{OT-LRTM} A one-time linkable ring threshold multisignature scheme is a set of PPT algorithms (\texttt{UserKeyGen}, \texttt{Merge}, \texttt{TxnKeyGen}, \texttt{Sign}, \texttt{Verify}, \texttt{Link}) that, respectively, generates usual private-public keypairs for users, generates public transaction keys, merges user keys into new shared user keys, fashions signatures on messages given a ring of public transaction keys, verifies signatures, and links signatures. Formally:
|
||||
\begin{enumerate}[(i)]
|
||||
\item $\texttt{UserKeyGen}(1^\lambda)$ outputs a random user key pair $(x,X)$ called a \textit{$1$-of-$1$ user key pair} where $x$ is a private user key with associated public user key $X$.
|
||||
|
||||
|
|
@ -142,37 +133,36 @@ We begin by defining a one-time linkable ring threshold multisignature (OT-LRTM)
|
|||
|
||||
\item $\texttt{TxnKeyGen}(1^\lambda, X)$ takes as input a public user key $X$ called the \textit{destination key}. A one-time random private-public transaction key pair $(q_X,Q_X)$ is generated. $\texttt{TxnKeyGen}$ outputs $Q_X$.
|
||||
|
||||
\item $\texttt{ImageGen}(1^\lambda, Q, y)$ takes as input a public transaction key $Q$ with a set of private user keys $y = \left\{x_1, \ldots\right\}$ and outputs a point $J_Q$ called the \textit{key image} for the private transaction key $q$ and outputs $J_Q$.
|
||||
%\item $\texttt{ImageGen}(1^\lambda, Q, y)$ takes as input a public transaction key $Q$ with a set of private user keys $y = \left\{x_1, \ldots\right\}$ and outputs a point $J_Q$ called the \textit{key image} for the private transaction key $q$ and outputs $J_Q$.
|
||||
|
||||
\item $\texttt{Sign}(M,X,R,k, y)$ takes as input message $M$, a destination user key $X$, ring of public transaction keys $R=\left\{Q_1, \ldots, Q_L\right\}$, secret index $k$, and a set of private user keys $y$. $\texttt{Sign}$ obtains $Q \leftarrow \texttt{TxnKeyGen}(1^\lambda, X)$, $J \leftarrow \texttt{ImageGen}(1^\lambda, Q, y)$. $\texttt{Sign}$ generates a signature $\sigma$ and publishes the signature-image pair $(\sigma, J)$.
|
||||
\item $\texttt{Sign}(M,X,\mathcal{Q},k, y)$ takes as input message $M$, a destination user key $X$, ring of public transaction keys $\mathcal{Q}=\left\{Q_1, \ldots, Q_L\right\}$, secret index $k$, and a set of private user keys $y$. A transaction key $Q^*$ addressed to $X$ is computed $Q^* \leftarrow \texttt{TxnKeyGen}(1^\lambda, X)$, a key image $J$ is generated, and a modified message $M^*=(M, J, Q^*, \mathcal{Q})$ is constructed. $\texttt{Sign}$ outputs $(\sigma, M^*)$.
|
||||
|
||||
\item $\texttt{Verify}(M,R,\sigma)$ takes as input a message $M$, a ring of public transaction keys $R$, and a signature $\sigma$, and outputs a bit $b \in \left\{0,1\right\}$.
|
||||
\item $\texttt{Verify}(M^*,\sigma)$ takes as input a message $M^* = (M, J, Q^*, \mathcal{Q})$ and a signature $\sigma$, and outputs a bit $b \in \left\{0,1\right\}$.
|
||||
|
||||
\item $\texttt{Link}((M_0,R_0,(\sigma_0, J_0)), (M_1,R_1,(\sigma_1, J_1)))$ takes as input two (possibly distinct) messages, two (possibly distinct) rings of transaction public keys, and two signature-image pairs. $\texttt{Link}$ outputs a bit $b \in \left\{0,1\right\}$.
|
||||
\item $\texttt{Link}((M^*_0, \sigma_0), (M^*_1, \sigma_1))$ takes as input two signatures on two messages and outputs a bit $b \in \left\{0,1\right\}$.
|
||||
\end{enumerate}
|
||||
\end{defn}
|
||||
|
||||
Note that a $1$-of-$1$ user key may be regarded as a ``usual'' user key in a one-time linkable ring signature scheme. In this way, we may regard all user keys as $t$-of-$N$ shared user keys by simply regarding $1$-of-$1$ keys as having a coalition of a single member. We consider only \textit{restricted} OT-LRTM schemes where $\texttt{Merge}$ is modified such that (i) if $t=1$ and $\left|C\right| = 1$, then $\texttt{Merge}$ returns the public user key in $C$, (ii) if the inequalities $2 \leq N-1 \leq t \leq N$ do not hold then $\texttt{Merge}$ outputs $\bot$ instead of a key.
|
||||
Note that a $1$-of-$1$ user key may be regarded as a ``usual'' user key in a one-time linkable ring signature scheme. In this way, we may regard all user keys as $t$-of-$N$ shared user keys by simply regarding $1$-of-$1$ keys as having a coalition of a single member. We consider only \textit{restricted} OT-LRTM schemes where $\texttt{Merge}$ is modified such that (i) if $t=1$ and $\left|C\right| = 1$, then $\texttt{Merge}$ returns the public user key in $C$, (ii) if the inequalities $2 \leq t$ and $2 \leq N$ and $N-1 \leq t \leq N$ do not hold then $\texttt{Merge}$ outputs $\bot$ instead of a key.
|
||||
|
||||
\begin{defn}
|
||||
Assume for each $i=0,1$, $M_i$ is an arbitrary message, $X_i$ is an arbitrary $t_i$-of-$N_i$ shared public user key with coalition $C_i$, $R_i=\left\{Q_{i,j}\right\}_{j=1}^{\left|R_i\right|}$ is an arbitrary ring of public transaction keys with associated secret indices $k_i$ such that $\texttt{dest}(Q_{i,k_i}) = X_i$, each $y_i$ is a set of private user keys such that $y_i \subseteq C_i$ and $t_i \leq \left|y_i\right|$, and each signature-tag pair $(\sigma_i, J_i)$ is honestly generated as $(\sigma_i, J_i) \leftarrow \texttt{Sign}(M_i,X_i,R_i,k_i,y_i)$. We say an OT-LRTM scheme is \textit{complete} if
|
||||
Assume for each $i \in \{0,1\}$ that $M_i$ is an arbitrary message, $X_i$ is an arbitrary $t_i$-of-$N_i$ shared public user key with coalition $C_i$, $\mathcal{Q}_i=\left\{Q_{i,j}\right\}_{j=1}^{\left|\mathcal{Q}_i\right|}$ is an arbitrary ring of public transaction keys with associated secret index $k_i$ such that $\texttt{dest}(Q_{i,k_i}) = X_i$, each $y_i$ is a set of private user keys such that $y_i \subseteq C_i$ and $t_i \leq \left|y_i\right|$, and each signature is generated fairly from $\sigma_i \leftarrow \texttt{Sign}(M_i,X_i,\mathcal{Q}_i,k_i,y_i)$. Further say $M^*_i = (M_i, J_i, Q^*_i, \mathcal{Q}_i)$. We say an OT-LRTM scheme is \textit{complete} if
|
||||
\begin{enumerate}[(a)]
|
||||
\item $\texttt{VER}(M_i,R_i,(\sigma_i,J_i)) = 1$ and
|
||||
\item if $Q_{i,k_i} = Q_{j,k_j}$ then $\texttt{LNK}((\sigma_i, J_i), (\sigma_j, J_j))=1$.
|
||||
\item $\texttt{VER}(M^*_i,\sigma_i) = 1$ and
|
||||
\item if $Q_{i,k_i} = Q_{j,k_j}$ then $\texttt{LNK}((M^*_i, \sigma_i), (M^*_j, \sigma_j))=1$.
|
||||
\end{enumerate}
|
||||
\end{defn}
|
||||
|
||||
|
||||
|
||||
Recall Remark \ref{hashed-keys} and consider the hash-then-encrypt-then-authenticate approach to computing shared public keys. We let $\Pi = (\texttt{UserKeyGen}^*,\texttt{Enc}^*, \texttt{Auth}^*, \texttt{Ver}^*, \texttt{Dec}^*)$ be a secure encrypt-then-authenticate scheme (where $\Pi_{\texttt{enc}} = (\texttt{Gen}^*,\texttt{Enc}^*, \texttt{Dec}^*)$ is a secure encryption sub-scheme and $\Pi_{\texttt{auth}} = (\texttt{Gen}^*,\texttt{Auth}^*, \texttt{Ver}^*)$ is a secure message authentication sub-scheme). Augmenting the implementation of Section \ref{naiveImplement} with $\Pi$ allows the coalition for $X_{\texttt{shared}}$ to compute the appropriate values to participate in the signing of a message in a recursive fashion. To see how, note that when the implementation of Section \ref{naiveImplement} is carried out, this $t$-of-$N$ shared public user key $X_{\texttt{shared}}$ must first compute the partial key image, next select a random secret scalar $u_j$, then compute the commitments $c_k$, and finally must compute the value $s_{k,j} = u_j - c_k (H_s(a_j R) + b_j)$.
|
||||
Recall Remark \ref{hashed-keys} and consider the hash-then-encrypt-then-authenticate approach to computing shared public keys. We let $\Pi = (\texttt{UserKeyGen}^*,\texttt{Enc}^*, \texttt{Auth}^*, \texttt{Ver}^*, \texttt{Dec}^*)$ be a secure encrypt-then-authenticate scheme (where $\Pi_{\texttt{enc}} = (\texttt{Gen}^*,\texttt{Enc}^*, \texttt{Dec}^*)$ is a secure encryption sub-scheme and $\Pi_{\texttt{auth}} = (\texttt{Gen}^*,\texttt{Auth}^*, \texttt{Ver}^*)$ is a secure message authentication sub-scheme). Augmenting the implementation of Section \ref{naiveImplement} with $\Pi$ allows the coalition for $X_{\texttt{shared}}$ to compute the appropriate values to participate in the signing of a message in a recursive fashion.
|
||||
|
||||
Denote the coalition of user key pairs for $X_{\texttt{shared}}$ as $\left\{((a_{j}, b_{j}), (A_{j}, B_{j}))\right\}$. The coalition for $X_\texttt{shared}$ may use $\Pi_{\texttt{auth}}$ to share their $(H_s(a_{j} S) + b_{j})\cdot H_p(Q)$ and compute the key image $J = (\sum_j H_s(a_{j})S + b_{j}) H_p(Q)$. If some index, say $j$, corresponds to a user key pair $((a_j,b_j),(A_j,B_j))$ that is a $t_j$-of-$N_j$ public key, then the secrets $a_j$ and $b_j$ are not known by the coalition and so the $j^{th}$ share of the key image, $J_j$, must be collaboratively computed by at least $t_j$ coalition members for the shared key $((a_j,b_j),(A_j,B_j))$. Denote the coalition for this key as $\left\{((a_{j,i}, b_{j,i}), (A_{j,i}, B_{j,i}))\right\}_{i=1}^{N_j}$. Each member computes their share, $J_{j,i} = (H_s(a_{j,i} S) + b_{j,i})H_p(Q)$, this sub-coalition uses $\Pi_{\texttt{auth}}$ to compute $J_j = \sum_i J_{j,i}$, and the sub-coalition reports $J_j$ when prompted.
|
||||
To see how, note that when the implementation of Section \ref{naiveImplement} is carried out, this $t$-of-$N$ shared public user key $X_{\texttt{shared}}$ must first compute the partial key image, next select a random secret scalar $u_j$, then compute the commitments $c_k$, and finally must compute the values $s_{k,j} = u_j - c_k b_j$, and then finally $s_k = (\sum_j s_{k,j}) - c_k H_s(a^* S)$. Denote the coalition of user key pairs for $X_{\texttt{shared}}=(A^*,B^*)$ as $\left\{((a_{j}, b_{j}), (A_{j}, B_{j}))\right\}$. The coalition for $X_\texttt{shared}$ may use $\Pi$ to share their $(H_s(a_{j} S) + b_{j})\cdot H_p(Q)$ and compute the key image $J = (H_s(a^* S) + \sum_j b_{j}) H_p(Q)$. If some index, say $j$, corresponds to a user key pair $((a_j,b_j),(A_j,B_j))$ that is a $t_j$-of-$N_j$ public key, then the secrets $a_j$ and $b_j$ are not known by the coalition and so the $j^{th}$ share of the key image, $J_j$, must be collaboratively computed by at least $t_j$ coalition members for the shared key $((a_j,b_j),(A_j,B_j))$. Denote the coalition for this key as $\left\{((a_{j,i}, b_{j,i}), (A_{j,i}, B_{j,i}))\right\}_{i=1}^{N_j}$. Each member computes their share, $J_{j,i} = b_{j,i}H_p(Q)$, this sub-coalition uses $\Pi$ to compute $J_j = (H_s(a_{j} S)H_p(Q) + \sum_i J_{j,i}$, and the sub-coalition outputs $J_j$.
|
||||
|
||||
Similarly the random scalar $u_j$ is computed as a sum $u_j = \sum_i u_{j,i}$ using $\Pi$. Now any of these coalition members may compute the commitments $c_k$ and disseminate this to the rest of the coalition with $\Pi_{\texttt{auth}}$. At that point each member of the coalition may compute their individual $s_{k,j,i} = u_{j,i} - c_k x_{j,i}$ and the coalition may use $\Pi_{\texttt{auth}}$ to compute $s_{k,j} = \sum_i s_{k,j,i}$. In this way, sub-coalitions are simply handled recursively.
|
||||
Similarly the random scalar $u_j$ is computed as a sum $u_j = \sum_i u_{j,i}$ using $\Pi$. Now any of these coalition members may compute the commitments $c_k$ and disseminate them to the rest of the coalition with $\Pi$. At that point each member of the coalition may compute their individual $s_{k,j,i} = u_{j,i} - c_k x_{j,i}$ and the coalition may use $\Pi_{\texttt{auth}}$ to compute $s_{k,j} = \sum_i s_{k,j,i}$. In this way, sub-coalitions are simply handled recursively.
|
||||
|
||||
\begin{disc}
|
||||
If an OT-LTRM scheme is secure under the CIK model from Definition \ref{threshIndist} in Section \ref{subsec:CIK}, then it is not feasible for any PPT algorithm to check whether the keys used as input for $\texttt{Merge}$ are $1$-of-$1$, so modifying the straightforward implementation by banning composite coalition keys is not feasible. Recursion seems to be a natural design choice.
|
||||
\end{disc}
|
||||
In Definition \ref{threshIndist}, we formalize the notion that keys cannot be feasibly determined by a PPT algorithm to be threshold keys or $1$-of-$1$ keys. If an OT-LTRM scheme is secure under that definition, then it is not feasible for any PPT algorithm to check whether the keys used as input for $\texttt{Merge}$ are $1$-of-$1$, so modifying the straightforward implementation above to prevent recursive formation of coalition keys is not feasible. \end{disc}
|
||||
|
||||
|
||||
\subsection{Coalition Indistinguishable Keys} \label{subsec:CIK}
|
||||
|
|
@ -181,11 +171,11 @@ Definition \ref{threshIndist} formalizes the idea that an adversary should not b
|
|||
|
||||
\begin{defn}[Coalition Indistinguishable Keys]\label{threshIndist} Let $\mathcal{A}$ be a PPT adversary. Let $N(-)$, $L(-)$ be polynomials.
|
||||
\begin{enumerate}[(i)]
|
||||
\item A set of user key pairs $S^* \subseteq \mathcal{K}_{\texttt{user}}$ with $\left|S\right|=N(\lambda)$ is generated where the $i^{th}$ key pair is $t_i$-of-$N_i$ public user key for some $2 \leq t_i \leq N_i \leq L(\lambda)$. The set of public keys $S = \left\{X_i \mid \exists (x_i, X_i) \in S^*\right\}$ is sent to $\mathcal{A}$.
|
||||
\item A set of user key pairs $S^* \subseteq \mathcal{K}_{\texttt{user}}$ with $\left|S^*\right|=N(\lambda)$ is generated where the $i^{th}$ key pair is $t_i$-of-$N_i$ public user key for some $t_i, N_i$ such that $2 \leq t_i \leq N_i \leq L(\lambda)$. The set of public keys $S = \left\{X_i \mid \exists (x_i, X_i) \in S^*\right\}$ is sent to $\mathcal{A}$.
|
||||
|
||||
\item $\mathcal{A}$ outputs $(\tau_0,C_0)$ where $C_0 \subseteq S$, $\tau_0 \in \mathbb{N}$, and $\tau_0 \leq \left|C_0\right|$.
|
||||
|
||||
\item A random pair $(\tau_1, C_1)$ is selected where $C_1 \subseteq S$, $\tau_1 \in \mathbb{N}$, $\tau_0 \neq \tau_1$, and $C_1 \neq C_0$. A random bit $b$ is selected. The key $X_{\tau_b,C_b} \leftarrow \texttt{Merge}(\tau_b, C_b)$ is sent to $\mathcal{A}$.
|
||||
\item A random pair $(\tau_1, C_1)$ is selected where $C_1 \subseteq S$, $\tau_1 \in \mathbb{N}$, $\tau_1 \leq \left|C_1\right|$, $\tau_0 \neq \tau_1$, and $C_1 \neq C_0$. A random bit $b$ is selected. The key $X_{\tau_b,C_b} \leftarrow \texttt{Merge}(\tau_b, C_b)$ is sent to $\mathcal{A}$.
|
||||
|
||||
\item $\mathcal{A}$ outputs a bit $b^{\prime}$. This counts as a success if $b=b^{\prime}$.
|
||||
\end{enumerate}
|
||||
|
|
@ -195,13 +185,10 @@ We say an OT-LRTM scheme has Coalition Indistinguishable Keys (CIK) if the adver
|
|||
%We make some remarks on the straightforward $N$-of-$N$ implementation in Section \ref{naiveImplement}.
|
||||
|
||||
|
||||
\begin{disc}
|
||||
Even taking the above modification into account, each $H_s(X_j, \mu_j)G$ must be communicated to the coalition. An adversary who can learn these points may simply check whether a given public key $X$ is the sum of some observed values of $H_s(X_j, \mu_j)G$, determining non-trivial information about coalition size. Hence, these points should be communicated with $\Pi$ if an OT-LRTM scheme is to satisfy Definition \ref{threshIndist}.
|
||||
\end{disc}
|
||||
|
||||
|
||||
\begin{disc}
|
||||
We may be tempted to strengthen Definition \ref{threshIndist} to take into account corruption oracle access on the part of the adversary. Unfortunately this leads to certain problems with the security definition. However, by using the hash-then-encrypt-then-authenticate method of computing shared public keys, without knowledge of the values of $\mu_j$, even if the adversary corrupts all the public keys in $S$, then $\mathcal{A}$ cannot successfully run $\texttt{Merge}$ for each value $1 \leq t \leq \left|S\right|$ to check the results by hand in comparison against the key $X_{t_b,C_b}$. Thus, if the participating coalition members keep each $\mu_j$ and $\mu_j G$ secret, then even a very powerful adversary with oracle access for computing discrete logs will still be unable to discern whether some user key is a coalition key or not.
|
||||
We may be tempted to strengthen Definition \ref{threshIndist} to take into account corruption oracle access on the part of the adversary. Unfortunately this leads to certain problems with the security definition. However, by using the hash-then-encrypt-then-authenticate method of computing shared public keys, without knowledge of the values of $\mu_j$, even if the adversary corrupts all the public keys in $S$ and has the ability to compute discrete logs, then $\mathcal{A}$ cannot successfully run $\texttt{Merge}$ for each threshold value $1 \leq t \leq \left|S\right|$ to check the results by hand in comparison against the key $X_{t_b,C_b}$. Thus, if the participating coalition members keep each $\mu_j$ and $\mu_j G$ secret, then even a very powerful adversary with corruption and discrete log oracle access will still be unable to discern whether some user key is a coalition key or not.
|
||||
\end{disc}
|
||||
%In \cite{bender2006ring}, anonymity in ring signatures assumes at least two honest users in each ring, because if the adversary controls all keys except a single key controlled by an honest user, that adversary can certainly identify whether that honest user fashioned a signature! %The adversary does not even need to know private information to violate coalition indistinguishability. %In fact, by merely knowing the CryptoNote public view key of a set $S$ of $N$ possible signers, an adversary may trivially check if some CryptoNote key pair $(A,B)$ is an $N$-of-$N$ key pair for the coalition $S$.
|
||||
|
||||
|
|
@ -212,31 +199,31 @@ Even taking the above modification into account, each $H_s(X_j, \mu_j)G$ must be
|
|||
|
||||
In addition to coalition indistinguishability, we desire the ring signature property of \textit{signer ambiguity}. Variations of security models appear in \cite{bender2006ring}.
|
||||
|
||||
Double spend protection in Monero relies on a one-time linkable ring signature scheme that is not signer ambiguous with respect to adversarially generated keys according to the definition presented in \cite{bender2006ring}. Indeed, in Monero, $\texttt{Link}$ simply checks if two key images $J_i$ are identical. In this way, the signer ambiguity game falls apart: $\mathcal{A}$ can obtain signature-tag pair $(\sigma_0, J_0)$ on $M_0$ using ring $R_0$ with $Q_{i_0} \in R_0$ and a pair $(\sigma_1, J_1)$ on $M_1$ using ring $R_1$ with $Q_{i_1} \in R_1$. Then, upon receipt of $(\sigma,J)$ in step (v), $\mathcal{A}$ can check if $J=J_0$ or $J=J_1$. The definition may be modified, however, to take key images into account.
|
||||
Double-spend protection in Monero relies on a one-time linkable ring signature scheme that is not signer ambiguous with respect to adversarially generated keys according to the definition presented in \cite{bender2006ring}. Indeed, in Monero, $\texttt{Link}$ simply checks if two key images $J_i$ are identical. In this way, the signer ambiguity game falls apart: $\mathcal{A}$ can obtain signature-tag pair $(\sigma_0, J_0)$ on $M_0$ using ring $R_0$ with $Q_{i_0} \in R_0$ and a pair $(\sigma_1, J_1)$ on $M_1$ using ring $R_1$ with $Q_{i_1} \in R_1$. Then, upon receipt of $(\sigma,J)$ in step (v), $\mathcal{A}$ can check if $J=J_0$ or $J=J_1$. The definition may be modified, however, to take key images into account.
|
||||
|
||||
|
||||
Let $\mathcal{SO}(-,-,-,-)$ be a signing oracle that takes as input $(M,X,R,k)$ (a message, a destination public user key, a ring of public transaction keys, and an index $k$) and outputs a valid signature-tag pair $(\sigma, J) \leftarrow \texttt{Sign}(M,X,R,k,y)$ for some set $y$ of private user keys.
|
||||
Let $\mathcal{SO}(-,-,-,-)$ be a signing oracle that takes as input $(M,X,\mathcal{Q},k)$ (a message, a destination public user key, a ring of public transaction keys, and an index $k$) and outputs a valid signature-tag pair $(\sigma, J) \leftarrow \texttt{Sign}(M,X,\mathcal{Q},k,y)$ for some set $y$ of private user keys.
|
||||
|
||||
\begin{defn}{[Linkable Signer Ambiguity v. Adversarially Generated Keys]}\label{def:ambig} Let $N(-), L(-)$ be a positive polynomial. Let $\mathcal{A}$ be a PPT adversary. Let $\mathcal{A}$ have access to $\mathcal{SO}$. Consider the following game:
|
||||
\begin{defn}{[Linkable Signer Ambiguity v. Adversarially Generated Keys]}\label{def:ambig} Let $N(-)$ be a positive polynomial. Let $\mathcal{A}$ be a PPT adversary. Let $\mathcal{A}$ have access to $\mathcal{SO}$. Consider the following game:
|
||||
\begin{enumerate}[(i)]
|
||||
|
||||
\item A set of user key pairs $S^* \subseteq \mathcal{K}_{\texttt{user}}$ is selected with $\left|S^*\right| = N(\lambda)$. The public keys in $S^*$ are sent to $\mathcal{A}$.
|
||||
|
||||
\item $\mathcal{A}$ outputs a set of user key pairs $S \subseteq S^*$.
|
||||
|
||||
\item For each public user key $X_i \in S$, a public transaction key $Q^*_i \leftarrow \texttt{TxnKeyGen}(1^\lambda, X_i)$ is generated and the set $R^* := \left\{Q^*_i\right\}$ is generated, randomly permuted, and then sent to $\mathcal{A}$.
|
||||
\item For each public user key $X_i \in S$, a public transaction key $Q^*_i$ addressed to $X_i$ is generated. The set $\mathcal{Q}^* := \left\{Q^*_i\right\} \subseteq \mathcal{K}_{\texttt{txn}}$ is constructed, randomly permuted, and then sent to $\mathcal{A}$.
|
||||
|
||||
\item $\mathcal{A}$ selects a message $M$, a destination public user key $X \in \mathcal{K}_{\texttt{user}}$, a ring of transaction public keys $R=\left\{Q_1, \ldots, Q_L\right\} \subseteq \mathcal{K}_{\texttt{txn}}$, and two indices $i_0 \neq i_1$ such that $\left\{Q_{i_0}, Q_{i_1}\right\} \subseteq R^* \cap R$.
|
||||
\item $\mathcal{A}$ outputs a message $M$, a destination public user key $X \in \mathcal{K}_{\texttt{user}}$, a ring of transaction public keys $\mathcal{Q}=\left\{Q_1, \ldots, Q_L\right\} \subseteq \mathcal{K}_{\texttt{txn}}$, and two indices $i_0 \neq i_1$ such that $\left\{Q_{i_0}, Q_{i_1}\right\} \subseteq \mathcal{Q} \cap \mathcal{Q}^*$.
|
||||
|
||||
\item A random bit $b$ is chosen. The signature-tag pair $(\sigma,J) \leftarrow \mathcal{SO}(M,X,R,i_b)$ is sent to $\mathcal{A}$.
|
||||
\item A random bit $b$ is chosen. The message $M^*=(M,J,Q^*,\mathcal{Q})$ and signature $\sigma \leftarrow \mathcal{SO}(M^*,X,\mathcal{Q},i_b)$ are sent to $\mathcal{A}$.
|
||||
|
||||
\item $\mathcal{A}$ outputs a bit $b^{\prime}$. The game counts as a success if (a) $b = b^{\prime}$ and (b) if $(M^{\prime},X^{\prime},R^{\prime},i)$ is a query from $\mathcal{A}$ to $\mathcal{SO}$, then the $i^{th}$ element of $R^{\prime}$ is not $Q_{i_0}$ or $Q_{i_1}$.
|
||||
\item $\mathcal{A}$ outputs a bit $b^{\prime}$. The game counts as a success if (a) $b = b^{\prime}$ and (b) if $(M^{\prime},X^{\prime},\mathcal{Q}^{\prime},i)$ is any query from $\mathcal{A}$ to $\mathcal{SO}$, then the $i^{th}$ element of $\mathcal{Q}^{\prime}$ is not $Q_{i_0}$ or $Q_{i_1}$.
|
||||
|
||||
\end{enumerate}
|
||||
We say the scheme is \textit{linkably signer ambiguous against adversarially generated keys} (LSA-AGK) if the probability that $\mathcal{A}$ succeeds is negligibly close to $1/2$ (with respect to $\lambda$).
|
||||
\end{defn}
|
||||
|
||||
Definition \ref{def:ambig} essentially modifies the signer ambiguity game in \cite{bender2006ring} by adding requirements in step (vi) requiring that $\mathcal{A}$ see in step (v) either the key image for $Q_{i_0}$ or the key image for $Q_{i_1}$ for the first time.
|
||||
Definition \ref{def:ambig} essentially modifies the signer ambiguity game in \cite{bender2006ring} by adding requirements in step (vi) that the transcript for $\mathcal{A}$ reveals the key images for $\left\{Q_{i_0}, Q_{i_1}\right\}$ for the first time in step (v).
|
||||
|
||||
\subsection{Unforgeability}
|
||||
|
||||
|
|
@ -247,11 +234,10 @@ Unforgeability of any threshold signature scheme must take into account subthres
|
|||
Given a $S = \left\{X_1, \ldots, X_N\right\} \subseteq \mathcal{K}_{\texttt{user}}$ where each $X_i \in S$ is a $t_i$-of-$N_i$ public user key, we say that any PPT adversary $\mathcal{A}$ with access to an oracle $\mathcal{O}(-)$ has had \textit{subthreshold oracle access} to $S$ if, for any $X_i \in S$, at most $t_{i}-1$ coalition members for $X_i$ appear in the transcript between $\mathcal{A}$ and $\mathcal{O}(-)$.
|
||||
\end{defn}
|
||||
|
||||
However, since $\texttt{Merge}$ allows inputs of arbitrary (possibly threshold) user keys, this definition is insufficient. %In fact, we must define the \textit{depth} of public keys to handle this issue appropriately. We say a user key pair resulting from $\texttt{UserKeyGen}$ has \texttt{depth} $0$. We define the depth of a user key $X_{\texttt{shared}} \leftarrow \texttt{Merge}(t,C)$ as $\texttt{depth}(X_{\texttt{shared}}) = \max\left\{\texttt{depth}(Y) \mid Y \in C\right\} + 1$.
|
||||
For notational convenience, we call $\mathcal{M}(-)$ an oracle that inverts $\texttt{Merge}$ by taking as input a public $t$-of-$N$ key $X$ and producing as output $(t,C)$, the threshold $t$ and coalition $C$ such that $X = \texttt{Merge}(t,C)$. For any subset $S \subseteq \mathcal{K}_{\texttt{user}}$, define $\mathcal{M}(S) = \cup_{Y \in S} \mathcal{M}(Y)$. This provides the iterative definition $\mathcal{M}^{i+1}(S) = \cup_{Y \in S}\mathcal{M}^{i}(Y)$. Define $\mathcal{M}^{\leftarrow}(Y) := \cup_i \mathcal{M}^i(Y)$.
|
||||
However, since $\texttt{Merge}$ allows inputs of arbitrary (possibly threshold) user keys, this definition is insufficient. %At the risk of abusing notation, we call $\texttt{Merge}^{-1}(-)$ an oracle that inverts $\texttt{Merge}$ by taking as input a public $t$-of-$N$ key $X$ and producing as output $\texttt{Merge}^{-1}(X)=C$ such that $X = \texttt{Merge}(t,C)$ for some $t$. If $X$ is a usual user key, $\texttt{Merge}^{-1}(X)=(1,\left\{X\right\})$. We can apply $\texttt{Merge}^{-1}$ to sets of keys by taking the union of the output, $\texttt{Merge}^{-1}\left(\left\{X_1, \ldots, X_L\right\}\right) = \cup_{i=1}^{L} \texttt{Merge}^{-1}(X_i)$. We can define $\texttt{Merge}^{-1}\left(\texttt{Merge}^{-1}(X)\right) = \texttt{Merge}^{-2}(X) = \cup_{Y \in \texttt{Merge}^{-1}(X)} \texttt{Merge}^{-1}(Y)$, and so on iteratively. For any public key $X$, the sequence of sets $\left\{\texttt{Merge}^{-i}(X)\right\}_{i=1,2,\ldots}$ eventually terminates at the empty set. In other words, for any public key $X$, there exists an integer $\tilde{k}$ such that $\texttt{Merge}^{-i}(X) = \emptyset$ for any $i \geq \tilde{k}$. Define $\texttt{Merge}^{\leftarrow}(X) = \cup_i \texttt{Merge}^{-i}(X)$, which is the \textit{the set of all public user keys contributing to $X$}.
|
||||
|
||||
\begin{defn}{[Subthreshold Oracle Access]}\label{def:prot:subthresh}
|
||||
Let $S$ be a set of public user keys $S = \left\{X_1, \ldots, X_N\right\}$ where each $X_i$ is a $t_i$-of-$N_i$ public user key. We say that any PPT adversary $\mathcal{A}$ with access to an oracle $\mathcal{O}(-)$ has had \textit{subthreshold oracle access} to $S$ if, for any public user key $Y \in \mathcal{M}^{\leftarrow}(S)$, if $Y$ is a $t_Y$-of-$N_Y$ shared public user key, then at most $t_{Y}-1$ coalition members from $\mathcal{M}(Y)$ appear in the transcript between $\mathcal{A}$ and $\mathcal{O}(-)$.
|
||||
Let $S$ be a set of public user keys $S = \left\{X_1, \ldots, X_N\right\}$ where each $X_i$ is a $t_i$-of-$N_i$ public user key. We say that any PPT adversary $\mathcal{A}$ with access to an oracle $\mathcal{O}(-)$ has had \textit{subthreshold oracle access} to $S$ if, for any public user key $Y \in \texttt{Merge}^{\leftarrow}(S)$, if $Y$ is a $t_Y$-of-$N_Y$ shared public user key, then at most $t_{Y}-1$ coalition members from $\texttt{Merge}^{-1}(Y)$ appear in the transcript between $\mathcal{A}$ and $\mathcal{O}(-)$.
|
||||
\end{defn}
|
||||
|
||||
|
||||
|
|
@ -259,7 +245,7 @@ Let $S$ be a set of public user keys $S = \left\{X_1, \ldots, X_N\right\}$ where
|
|||
|
||||
%In this definition, we grant $\mathcal{A}$ access to $\mathcal{SO}$ as before but also $\mathcal{CO}_{\texttt{user}}(-)$, a user key corruption oracle. $\mathcal{CO}_{\texttt{user}}(-)$ accepts as input a public user key and produces as output the associated private user key.
|
||||
|
||||
Also for notational convenience, we call $\mathcal{T}(-)$ an oracle that inverts $\texttt{TxnKeyGen}$ by taking as input a public transaction key $Q_X$ and produces as output the user key $X$.
|
||||
Also for notational convenience, we call $\texttt{TxnKeyGen}^{-1}(-)$ an oracle that inverts $\texttt{TxnKeyGen}$ by taking as input a public transaction key $Q_X$ and produces as output the user key $X$. Let $\mathcal{CO}(-)$ be a corruption oracle that takes as input a public user key and outputs the associated private user key.
|
||||
|
||||
|
||||
|
||||
|
|
@ -267,19 +253,19 @@ Also for notational convenience, we call $\mathcal{T}(-)$ an oracle that inverts
|
|||
|
||||
|
||||
|
||||
\begin{defn}{[Existential Unforgeability v. Adaptive Chosen Message and Subthreshold Insider Corruption]}\label{steuf} Let $\mathcal{A}$ be a PPT adversary and $L(-)$ be polynomials. $\mathcal{A}$ is given access to a signing oracle $\mathcal{SO}$, a corruption oracle $\mathcal{CO}_{\texttt{user}}$. Consider the following game:
|
||||
\begin{defn}{[Existential Unforgeability v. Adaptive Chosen Message and Subthreshold Insider Corruption]}\label{steuf} Let $\mathcal{A}$ be a PPT adversary and $N(-)$ be a polynomials. $\mathcal{A}$ is given access to a signing oracle $\mathcal{SO}$, a corruption oracle $\mathcal{CO}_{\texttt{user}}$. Consider the following game:
|
||||
|
||||
\begin{enumerate}[(i)]
|
||||
\item A set of user key pairs $S^* \subseteq \mathcal{K}_{\texttt{user}}$ is selected with $\left|S^*\right| = N(\lambda)$. The public keys in $S^*$ are sent to $\mathcal{A}$.
|
||||
\item $\mathcal{A}$ outputs a set of user key pairs $S \subseteq S^*$.
|
||||
\item For each public user key $X_i \in S$, a public transaction key $Q_i^* \leftarrow \texttt{TxnKeyGen}(1^\lambda, X_i)$ is generated and the set $R^* := \left\{Q_i^*\right\}$ is constructed, randomly permuted, and then sent to $\mathcal{A}$.
|
||||
\item $\mathcal{A}$ outputs a message $M$, a destination public user key $X \in \mathcal{K}_{\texttt{user}}$, ring $R \subseteq \mathcal{K}_{\texttt{txn}}$ of public transaction keys, and a signature $\sigma$. The game counts as a success if
|
||||
\item For each public user key $X_i \in S$, a public transaction key $Q_i^* \leftarrow \texttt{TxnKeyGen}(1^\lambda, X_i)$ is generated and the set $\mathcal{Q}^* := \left\{Q_i^*\right\}$ is constructed, randomly permuted, and then sent to $\mathcal{A}$.
|
||||
\item $\mathcal{A}$ outputs a message $M$, a destination public user key $X \in \mathcal{K}_{\texttt{user}}$, ring $\mathcal{Q} \subseteq \mathcal{K}_{\texttt{txn}}$ of public transaction keys, and a signature $\sigma$. The game counts as a success if
|
||||
\begin{enumerate}[(a)]
|
||||
\item $R \subseteq R^*$,
|
||||
\item $\texttt{VER}(M,R,\sigma)=1$,
|
||||
\item for each index $k$ in $R$, $(M,X,R,k)$ does not appear in the queries between $\mathcal{A}$ and $\mathcal{SO}$
|
||||
\item for each $Q_k \in R$, $\mathcal{CO}_{\texttt{user}}$ is not queried with the public user key $\mathcal{T}(Q_k)$, and
|
||||
\item $\mathcal{A}$ has had subthreshold $\mathcal{CO}_{\texttt{user}}$ access to the set $\left\{\mathcal{T}(Q_k) \mid Q_k \in R\right\}$.
|
||||
\item $\mathcal{Q} \subseteq \mathcal{Q}^*$,
|
||||
\item $\texttt{VER}(M,\sigma)=1$,
|
||||
\item for each index $k$ in $R$, $(M,X,\mathcal{Q},k)$ does not appear in the queries between $\mathcal{A}$ and $\mathcal{SO}$
|
||||
\item for each $Q_k \in \mathcal{Q}$, $\mathcal{CO}_{\texttt{user}}$ is not queried with the public user key $\texttt{TxnKeyGen}^{-1}(Q_k)$, and
|
||||
\item $\mathcal{A}$ has had subthreshold $\mathcal{CO}_{\texttt{user}}$ access to the set $\left\{\texttt{TxnKeyGen}^{-1}(Q_k) \mid Q_k \in R\right\}$.
|
||||
|
||||
\end{enumerate}
|
||||
\end{enumerate}
|
||||
|
|
@ -292,45 +278,46 @@ A scheme in which an adversary is only negligibly likely to succeed is said to b
|
|||
|
||||
\section{Proposed Implementation}\label{sec:implement}
|
||||
|
||||
We provide an implementation of a restricted OT-LRTM scheme allowing only for $N-1 \leq t \leq N$ in the spirit of the original CryptoNote methodology. User secret keys and public keys are both ordered pairs of keys, i.e.\ private key $(a,b)$ and public key $(A,B)$. Following terminology from \cite{van2013cryptonote}, we refer to $(a,A)$ as the \textit{view keypair} and $(b,B)$ and the \textit{spend keypair}. We let $\Pi = (\texttt{Gen}^*,\texttt{Enc}^*, \texttt{Auth}^*, \texttt{Ver}^*, \texttt{Dec}^*)$ be a secure encrypt-then-authenticate scheme (where $\Pi_{\texttt{enc}} = (\texttt{Gen}^*,\texttt{Enc}^*, \texttt{Dec}^*)$ is a secure encryption sub-scheme and $\Pi_{\texttt{auth}} = (\texttt{Gen}^*,\texttt{Auth}^*, \texttt{Ver}^*)$ is a secure message authentication sub-scheme). %We use both of these schemes for computing sums, so the encryption and decryption algorithms may be taken as an homomorphic encryption scheme.
|
||||
We provide an implementation of a restricted OT-LRTM scheme allowing only for $N-1 \leq t \leq N$ in the spirit of the original CryptoNote methodology. We assume a coordinating member of the coalition is constructing the signature and has persuaded threshold members to participate. User secret keys and public keys are both ordered pairs of keys, i.e.\ private key $(a,b)$ and public key $(A,B)$. Following terminology from \cite{van2013cryptonote}, we refer to $(a,A)$ as the \textit{view keypair} and $(b,B)$ and the \textit{spend keypair}. We let $\Pi = (\texttt{Gen}^*,\texttt{Enc}^*, \texttt{Auth}^*, \texttt{Ver}^*, \texttt{Dec}^*)$ be a secure encrypt-then-authenticate scheme (where $\Pi_{\texttt{enc}} = (\texttt{Gen}^*,\texttt{Enc}^*, \texttt{Dec}^*)$ is a secure encryption sub-scheme and $\Pi_{\texttt{auth}} = (\texttt{Gen}^*,\texttt{Auth}^*, \texttt{Ver}^*)$ is a secure message authentication sub-scheme). %We use both of these schemes for computing sums, so the encryption and decryption algorithms may be taken as an homomorphic encryption scheme.
|
||||
\begin{enumerate}[(I)]
|
||||
\item \texttt{UserKeyGen} generates the secret key $z=(a,b)$ by selecting $a,b$ from an i.i.d.\ uniform distribution on $\mathbb{Z}_q$, and computing $Z=(A,B)$ with $A:=aG$ and $B:=bG$. \texttt{UserKeyGen} then outputs $(z,Z)$.
|
||||
|
||||
\texttt{UserKeyGen} generates the secret key $z=(a,b)$ by selecting $a,b$ from an i.i.d.\ uniform distribution on $\mathbb{Z}_q$, and computing $Z=(A,B)$ with $A:=aG$ and $B:=bG$. \texttt{UserKeyGen} then outputs $(z,Z)$.
|
||||
|
||||
\texttt{Merge} takes as input a threshold $t$ and a set of key pairs $C=\left\{(z_1,Z_1), \ldots, (z_n,Z_N)\right\}$ such that $2 \leq N-1 \leq t \leq N$ where each $Z_i = (A_i,B_i)$. If $N=1$, $\texttt{Merge}$ outputs $Z_1$. Otherwise:
|
||||
\item \texttt{Merge} takes as input a threshold $t$ and a set of key pairs $C=\left\{(z_1,Z_1), \ldots, (z_n,Z_N)\right\}$ such that $2 \leq t$ and $2 \leq N$ and $N-1 \leq t \leq N$ where each $Z_i = (A_i,B_i)$, and outputs a shared public user key $Z_{\texttt{shared}}$.
|
||||
\begin{enumerate}[(1)]
|
||||
\item Each member of the coalition selects constants $\mu_i, \gamma_i$ for the multisig address.
|
||||
\item Each member derives a partial secret keypair $(a^*_i, b^*_i)$ where $a^*_i = H_s(a_i, \mu_i)$ and $b^*_i = H_s(b_i, \gamma_i)$ and computes their associated public points $A^*_i=a^*_i G$, $B^*_i = b^*_i G$.
|
||||
\item Each member derives a partial secret keypair $(a^*_i, b^*_i)$ where $a^*_i = H_s(a_i, \mu_i)$ and $b^*_i = H_s(b_i, \gamma_i)$ and computes their associated public points $A^*_i=a^*_i G$ and $B^*_i = b^*_i G$.
|
||||
%\item Each member uses $\Pi_{\texttt{auth}}$ to send $(A^*_i, B^*_i)$ to the coalition.
|
||||
\item If $t=N$, then the coalition uses $\Pi$ to collaboratively compute the shared secret view key $a^* = \sum_i a^*_i$\footnote{Note that although secret information is about $a_i$ not being directly shared with the coalition, the result of the computation is, in fact, a secret key, $a^*$.}, uses $\Pi_{\texttt{auth}}$ to collaboratively compute the shared public spend key $B^* = \sum_{i=1}^{N} B^*_i$. If $t=N-1$, then %, and then uses $\Pi$ to collaboratively compute the key image $J = \sum_{i=1}^{N} b^*_i H_p(B^*)$.:
|
||||
\item If $t=N$, then each coalition member uses $\Pi$ to send $a^*_i$ to the coordinating user, who computes the shared secret view key $a^* = \sum_i a^*_i$\footnote{Note that although secret information is about $a_i$ not being directly shared with the coalition, the result of the computation is, in fact, a secret key, $a^*$.} The coordinating user computes the shared public spend key $B^* = \sum_{i=1}^{N} B^*_i$. The coordinating user outputs $(A^*, B^*)$, which may be made public.
|
||||
\item If $t=N-1$, then
|
||||
\begin{enumerate}[(a)]
|
||||
\item For each $i,j$, a partial shared secret view key $\alpha_{i,j} := H_s(a^*_iA^*_i)$ and a partial shared secret spend key $\beta_{i,j} := H_s(b^*_iB^*_i)$ is computed by either participant $i$ or $j$.
|
||||
\item For each $i,j$, a partial shared secret view key $\alpha_{i,j} := H_s(a^*_iA^*_j)$ and a partial shared secret spend key $\beta_{i,j} := H_s(b^*_iB^*_j)$ is computed by either participant $i$ or $j$.
|
||||
\item Set $N^* := \frac{N(N+1)}{2}$, $S^* := \left\{((\alpha_{i,j},\beta_{i,j}), (\alpha_{i,j}G, \beta_{i,j}G))\right\}_{1 \leq i < j \leq N}$, and run $\texttt{Merge}(N^*, S^*)$.
|
||||
\end{enumerate}
|
||||
\item Every coalition member now knows the shared secret view key $a^*$ and the shared public spend key $B^*$.
|
||||
|
||||
\end{enumerate}
|
||||
|
||||
\texttt{TxnKeyGen} takes as input a destination user public key $(A,B)$, selects a random scalar $r$, computes $R=rG$ and $P = H_s(rA)G + B$, and outputs $(R,P)$.
|
||||
\item \texttt{TxnKeyGen} takes as input a set of destination user public keys $\left\{(A_i,B_i)\right\}_{i}$. For each destination, the coordinating user selects a random scalar $s_i$, computes $S_i=s_iG$ and $P_i = H_s(s_iA_i)G + B_i$, outputs the (public) pairs $\left\{(S_i,P_i)\right\}_i$.%The coalition uses $\Pi$ to share $s$ with each other and
|
||||
|
||||
\texttt{ImageGen} takes as input a set of private user keys $y = \left\{(a_1, b_1), \ldots, (a_N, b_N)\right\}$ and a public transaction key $(R,P)$. For each $i=1,\ldots,N$, the $i^{th}$ member of $y$ computes partial key image $J_i = (H_s(a_i R)+ b_i)H_p(R,P)$. The participating members use $\Pi_\texttt{auth}$ to compute $J = \sum_i J_i$.
|
||||
%\item \texttt{ImageGen} takes as input a set of private user keys $y = \left\{(a_1, b_1), \ldots, (a_N, b_N)\right\}$ and a public transaction key $(R,P)$. For each $i=1,\ldots,N$, the $i^{th}$ member of $y$ computes partial key image $J_i = (H_s(a_i R)+ b_i)H_p(R,P)$. The participating members use $\Pi_\texttt{auth}$ to compute $J = \sum_i J_i$.
|
||||
|
||||
\texttt{Sign} takes as input a message $M$, a destination public user key $(A_{\texttt{dest}}, B_{\texttt{dest}})$, a set of public transaction keys $\left\{(R_1, P_1), \ldots, (R_L, P_L)\right\}$, a secret index $1 \leq k \leq L$, and a set of $t$ private keys $y=\left\{(a^*_i, b^*_i)\right\}_{i=1}^{t}$.
|
||||
\item \texttt{Sign} takes as input a message $M$, a destination public user key $(A_{\texttt{dest}}, B_{\texttt{dest}})$, a set of input public transaction keys $\left\{(S_i, P_i)\right\}_{i=1}^{I}$, a set of output public transaction keys $\left\{(\widetilde{S}_d, \widetilde{P}_d)\right\}_{d=1}^{D}$, a secret index $1 \leq i^* \leq I$, and a set of $t$ user private keys $y=\left\{(a^*_n, b^*_n)\right\}_{n=1}^{t}$ such that $a^*_n = a^*_m$ for each $n,m$.
|
||||
\begin{enumerate}[(1)]
|
||||
\item The points $(R^*, P^*) \leftarrow \texttt{TxnKeyGen}(1^\lambda, (A_{\texttt{dest}}, B_{\texttt{dest}}))$ are computed.
|
||||
\item The owners of $y=\left\{(a^*_i, b^*_i)\right\}$ (the \textit{signatories}) run $J \leftarrow \texttt{ImageGen}(1^\lambda, (R_k, P_k), y)$
|
||||
\item A set $\left\{s_{k+1}, s_{k+2}, \ldots, s_{k-1}\right\}$ of i.i.d.\ observations of uniform random variables are generated by the coalition and shared among the coalition using $\Pi_{\texttt{auth}}$.\footnote{We recommend that a coordinating user randomly selects these using a cryptographic random number generator; only the user coordinating the signature needs these values.}
|
||||
\item For each $j$, the $j^{th}$ signatory selects a random scalar $u_{j}$, computes $H_i:=H_{p}(B_i)$ for each index $1 \leq i \leq L$, and computes the points $u_jG$ and $u_jH_{k}$. The coalition uses $\Pi_{\texttt{auth}}$ to collaboratively compute $u_{k}G := \sum_j u_j G$ and $u_k H_k:= \sum_j u_j H_{k}$.
|
||||
\item The coalition computes $(S^*, P^*) \leftarrow \texttt{TxnKeyGen}(1^\lambda, (A_{\texttt{dest}}, B_{\texttt{dest}}))$.
|
||||
\item For each $(a_i, b_i) \in y$, the points $b_i H_p(S_k, P_k)$ are computed and communicated with $\Pi$ to the coalition. The sum $\sum_i b_i H_p(S_k, P_k)$ is computed together with the key image $J = (H_s(a^*_1 S_k)+\sum_i b_i)H_p(S_k, P_k)$ by any member of the coalition and shared with the coalition using $\Pi$.
|
||||
\item The coalition computes $M^* = (M, J, S^*, P^*, \mathcal{Q})$.
|
||||
\item A set $\left\{s_{k+1}, s_{k+2}, \ldots, s_{k-1}\right\}$ of i.i.d.\ observations of uniform random variables are generated by the coalition and shared among the coalition using $\Pi$.
|
||||
|
||||
\item For each $j$, the $j^{th}$ signatory selects a random scalar $u_{k,j}$, computes $H_i:=H_{p}(B_i)$ for each index $1 \leq i \leq L$, and computes the points $u_{k,j}G$ and $u_{k,j}H_{k}$. The coalition uses $\Pi$ to collaboratively compute $u_{k}G := \sum_j u_{k,j} G$ and $u_k H_k:= \sum_j u_{k,j} H_{k}$.
|
||||
|
||||
\item Some threshold member computes
|
||||
\begin{align*}
|
||||
c_{k+1} =& H_{p}(m, u_{k} G, u_{k} H_{k})\text{ and }\\
|
||||
c_{i+1} =& H_{p}(m, s_i G + c_i B_i, s_i H_{i} + c_i J)\text{ for }i=k+1, k+2, \ldots, k-1.
|
||||
c_{k+1} =& H_{p}(M^*, u_{k} G, u_{k} H_{k})\text{ and }\\
|
||||
c_{i+1} =& H_{p}(M^*, s_i G + c_i P_i, s_i H_{i} + c_i J)\text{ for }i=k+1, k+2, \ldots, k-1.
|
||||
\end{align*}
|
||||
\item The threshold member from the previous step uses $\Pi_{\texttt{auth}}$ to send $c_{k}$ to all other signers with authentication. These signers may check that their received $c_k$ matches their expected computations.
|
||||
\item If $t=N$, each signatory computes their personal $s_{k,j} := u_j - c_{k} b_j^*$. If $t=N-1$, each signatory computes $s_{k,j} = u_j - c_{k} \sum_{i=1}^{L}z_{i,j}$. The coalition uses $\Pi_{\texttt{auth}}$ to collaboratively compute $s_k = \sum_j s_{k,j}$ and construct the signature $\sigma = (c_1, s_1, s_2, \ldots, s_L)$.
|
||||
\item Any signatory may now publish the signature-tag pair $(\sigma, J)$ where $\sigma=(c_1, s_1, \ldots, s_N)$ together with the public transaction key $(R^*, P^*)$.
|
||||
\item The threshold member from the previous step uses $\Pi$ to send $c_{k}$ to all other signers with authentication. These signers may check that their received $c_k$ matches their expected computations.
|
||||
\item If $t=N$, each signatory computes their personal $s_{k,j} := u_j - c_{k} b_j^*$. If $t=N-1$, each signatory computes $s_{k,j} = u_j - c_{k} \sum_{i=1}^{L}z_{i,j}$. The coalition uses $\Pi$ to collaboratively compute $s_k = \sum_j s_{k,j}$ and construct $\sigma = (c_1, s_1, s_2, \ldots, s_L)$.
|
||||
\item Any signatory may now publish the signature $\sigma=(c_1, s_1, \ldots, s_N)$, and any verifier may use the usual MLSAG verification to check that some member of the ring $\left\{(S_i, P_i)\right\}$ fashioned the signature.
|
||||
\end{enumerate}
|
||||
\end{enumerate}
|
||||
|
||||
|
||||
\begin{disc} The resulting signature takes the same form as LSAG signatures as in \cite{liu2004linkable}. Modifying the above to appropriately to take into account key vectors provides the generalization to MLSAG signatures. Thus the verification algorithm for these signatures is identical to the verification algorithm for usual MLSAG signatures and we omit its description. Similarly, $\texttt{Link}$ merely outputs a bit signifying whether two key images are identical, so we don't describe it further either.
|
||||
|
||||
|
|
@ -349,6 +336,10 @@ We provide an implementation of a restricted OT-LRTM scheme allowing only for $N
|
|||
\begin{disc} Note that users in $(N-1)$-of-$N$ processes are prompted to select constants $\mu, \gamma$ multiple times for multiple sets of keys. If our hash function $H_s(-)$ is suitably secure, the lazy user can re-use the same constants $\mu$ and $\gamma$ without concern; nevertheless, it is recommended that users do not re-use constants in $\texttt{Merge}$.
|
||||
\end{disc}
|
||||
|
||||
\begin{disc}
|
||||
When a transaction is relayed on the Monero network, the transaction key pair $(S,P)$ is scanned by any of the coalition members. Any of these members can use their shared secret view key $a^*$ to check whether $B^* = P - H_s(a^* S)G$. If so, they can execute $\texttt{Sign}$ to sign a message with the private key $p$ without revealing it.
|
||||
\end{disc}
|
||||
|
||||
|
||||
\section{Security}
|
||||
|
||||
|
|
@ -361,19 +352,40 @@ We provide an implementation of a restricted OT-LRTM scheme allowing only for $N
|
|||
|
||||
|
||||
\begin{theorem}
|
||||
The restricted OT-LRTM implementation from Section \ref{sec:implement} is CIK.
|
||||
If $H_s$ is a secure hash function under the random oracle model, the restricted OT-LRTM implementation from Section \ref{sec:implement} is CIK.
|
||||
\end{theorem}
|
||||
\begin{proof}
|
||||
Either the key pair $X_b = (A,B)$ received by $\mathcal{A}$ in step (iii) of Definition \ref{threshIndist} is $N$-of-$N$ for some $N \geq 2$, $(N-1)$-of-$N$ for some $N \geq 3$, or a mere $1$-of-$1$ user key. Of course, $(N-1)$-of-$N$ key pairs are $N^*$-of-$N^*$ key pairs. Thus, we really only need to deal with two cases: an $N$-of-$N$ key pair with $N > 1$ or a $1$-of-$1$ key pair.
|
||||
|
||||
If $(A,B)$ is an $N$-of-$N$ key pair, then $A^* = \sum_{i} H_s(a_i, \mu_i) G$ and $B^* = \sum_i H_s(b_i, \gamma_i) G$. Since $H_s$ is a random oracle, any one of its outputs is uniformly random, and so any sum of its outputs is uniformly random \cite{scozzafava1993uniform}, so no PPT adversary may determine the number of signatories. On the other hand, if $(A,B)$ is a $1$-of-$1$ key pair, then $A$ and $B$ are each independent uniform random variables from $\texttt{UserKeyGen}$, so no PPT algorithm can determine whether $A$ or $B$ is a sum or not.
|
||||
If $(A,B)$ is an $N$-of-$N$ key pair, then the keys defined in $\texttt{Merge}$ are $A^* = \sum_{i} H_s(a_i, \mu_i) G$ and $B^* = \sum_i H_s(b_i, \gamma_i) G$. Since $H_s$ is a random oracle, any one of its outputs is uniformly random, and so any sum of its outputs is uniformly random \cite{scozzafava1993uniform}, so no PPT adversary may determine the number of signatories. On the other hand, if $(A,B)$ is a $1$-of-$1$ key pair, then $A$ and $B$ are each independent uniform random variables from $\texttt{UserKeyGen}$, so no PPT algorithm can determine whether $A$ or $B$ is a sum or not.
|
||||
|
||||
\end{proof}
|
||||
|
||||
\begin{theorem} The OT-LRTM implementation from Section \ref{sec:implement} is LSA-AGK.
|
||||
\begin{theorem} If the Decisional Diffie Hellman hardness assumption holds in $\mathbb{G}$, then the OT-LRTM implementation from Section \ref{sec:implement} is LSA-AGK.
|
||||
\end{theorem}
|
||||
\begin{proof}
|
||||
$\mathcal{A}$ selects transaction public keys as ring members $(R_0, P_0) = (r_0 G, H_s(r_0 A_0)G + B_0)$ and $(R_1, P_1) = (r_1 G, H_s(r_1 A_1)G + B_1)$, a message $M$, a destination key pair $(A_{\texttt{dest}}, B_{\texttt{dest}})$ and receives a signature-tag pair $(\sigma, J_b)$. $\mathcal{A}$ can compute $H_p(R_b, P_b)$ for each $b \in \left\{0,1\right\}$, but without knowing the secrets $a_b, b_b$, computing $J_b = (H_s(a_b R_b) + b_b)H_p(R_b, P_b)$ for either $b$ is infeasible for PPT $\mathcal{A}$. Moreover, $\sigma$ has the same security properties as in \cite{liu2004linkable}.\footnote{WORK ON THIS}
|
||||
Assume $\mathcal{A}$ has a non-negligible advantage in the game of Definition \ref{def:ambig} played with the above implementation, namely let us say there exists some polynomial $f_1(\lambda)$ such that
|
||||
\[\mathbb{P}\left[\mathcal{A}\text{ succeeds in Definition \ref{def:ambig}}\right] > \frac{1}{2} + \frac{1}{f_1(\lambda)}\]
|
||||
|
||||
|
||||
We construct an algorithm $\mathcal{M}$ that gains a non-negligible advantage in solving the DDH game by running $\mathcal{A}$ as a subroutine, leading us to a contradiction. A base point $G$ is chosen and given to $\mathcal{M}$. Random scalars $r$, $s$, and $t$ are selected, a random bits $c \in \left\{0,1\right\}$ are chosen. The points $Q_0 = tG$, $Q_1 = rsG$, $Q_2 = rG$, $Q_3 = sG$ are computed. The points $(Q_c, Q_2,Q_3)$ are given to $\mathcal{M}$, who outputs a bit $c^{\prime}$. The game counts as a success if $c=c^{\prime}$.
|
||||
|
||||
The algorithm $\mathcal{M}$ receives $(Q_1^*, Q_2^*, Q_3^*)$ and executes part (i) from Definition \ref{def:ambig} by calling $\texttt{UserKeyGen}(1^{\lambda})$, and calls $\mathcal{A}$ to execute (ii) as usual. In (iii), $\mathcal{M}$ constructs $\mathcal{Q}^*$ to include $Q_i^*$ for $i=1,2,3$ in the following way. First, $\mathcal{M}$ instructs $\mathcal{A}$ to select three user public keys $X_1, X_2, X_3 \in S$, picks a random permutation $\tau \in S_3$, and assigns $\texttt{dest}(Q_i^*):=X_{\tau(i)}$ for each $i=1,2,3$. Next, $\mathcal{M}$ calls $\texttt{TxnKeyGen}$ using the other members of $S$ as usual to build $\mathcal{Q}^*$. Denote the index for $Q_i^*$ in $\mathcal{Q}^*$ as $j_i$ for $i=1,2,3$. Now $\mathcal{M}$ instructs $\mathcal{A}$ to select $i_0 = j_1$ and $i_1 \in \left\{j_2, j_3\right\}$. Steps (v) and (vi) execute as usual. If $\mathcal{A}$ succeeds, then $\mathcal{M}$ outputs $c^{\prime}=1$, otherwise selects a random bit as an output. We have the following from the law of total probability.
|
||||
\begin{align*}
|
||||
\mathbb{P}\left[\mathcal{M}\text{ succeeds at DDH}\right] =& \mathbb{P}\left[\mathcal{M}(Q^*_1, Q^*_2, Q^*_3)=c \mid c=0\right]\mathbb{P}\left[c=0\right] + \mathbb{P}\left[\mathcal{M}(Q^*_1, Q^*_2, Q^*_3)=c \mid c=1\right]\mathbb{P}\left[c=1\right]
|
||||
\end{align*}
|
||||
Certainly, $\mathbb{P}\left[c=0\right] = \mathbb{P}\left[c=1\right] = \frac{1}{2}$. If $c=0$, then $\mathcal{A}$ did not succeed so $\mathcal{M}$ can only guess. In this case, $\mathbb{P}\left[\mathcal{M}(Q^*_1, Q^*_2, Q^*_3)=c \mid c=0\right] = \frac{1}{2}$. We have
|
||||
\begin{align*}
|
||||
\mathbb{P}\left[\mathcal{M}\text{ succeeds at DDH}\right] =& \frac{1}{4} + \frac{1}{2}\mathbb{P}\left[\mathcal{M}(Q^*_1, Q^*_2, Q^*_3)=c \mid c=1\right]
|
||||
\end{align*}
|
||||
Moreover, $\mathcal{M}$ outputs $1$ if and only if $\mathcal{A}$ has succeeded:
|
||||
\begin{align*}
|
||||
\mathbb{P}\left[\mathcal{M}\text{ succeeds at DDH}\right] =& \frac{1}{4} + \frac{1}{2}\mathbb{P}\left[\mathcal{A}\text{ succeeds in Definition \ref{def:ambig}}\right]\\
|
||||
>& \frac{1}{4} + \frac{1}{2}\left(\frac{1}{2} + \frac{1}{f(\lambda)}\right)\\
|
||||
>& \frac{1}{2} + \frac{1}{2f(\lambda)}
|
||||
\end{align*}
|
||||
|
||||
|
||||
\end{proof}
|
||||
|
||||
\begin{theorem} The OT-LRTM implementation from Section \ref{sec:implement} is st-EUF.
|
||||
|
|
@ -469,13 +481,23 @@ In total, if we define the \textit{depth} of $1$-of-$1$ public user key as depth
|
|||
|
||||
|
||||
|
||||
We speculate that modifications to the CryptoNote-styled constructions of key images may allow for stronger notions of signer ambiguity in the future without sacrificing robustness against double-spend attacks. For example, by taking key images as homomorphic commitments, two commitments may be linked if their difference is a commitment to zero without revealing their masks. This is beyond the scope of this document.
|
||||
%Modifications to the CryptoNote-styled constructions of key images may allow for stronger notions of signer ambiguity in the future without sacrificing robustness against double-spend attacks. For example, by taking key images as homomorphic commitments, two commitments may be linked if their difference is a commitment to zero without revealing their masks. This is beyond the scope of this document.
|
||||
|
||||
Can the notion of CIK be expanded to CIKS so as to include signatures and chosen messages? With an LRTM, this expansion is nontrivial but straightforward. With an OT-LRTM, this becomes a delicate generalization due to the one-time transaction keys.
|
||||
In \cite{bonehthreshold}, a very general fully homomorphic thresholdizing set-up is described, leading to fully homomorphic threshold signatures and encryption. The threshold signature scheme defined in \cite{bonehthreshold} generates a unique verification key (akin to our transaction keys) for each coalition and access structure, so the scheme in \cite{bonehthreshold} vacuously satisfies CIK. On the other hand, in our proposed implementation, keys are being combined into new keys, so it is critical to check that combined keys do not reveal anything about the participating members.
|
||||
|
||||
Coalition indistinguishability on keys is related to two distinct security notions defined in \cite{bonehthreshold}, where a highly general fully homomorphic thresholdizing scheme using only one round of communication is presented. Threshold signatures described in \cite{bonehthreshold} are required to be \textit{anonymous} and \textit{succinct}. Anonymity in \cite{bonehthreshold} is defined such that an adversary should be unable to discern which subset of the coalition produced the signature, and succinctness is defined such that signature size is dependent only on the security parameter.
|
||||
|
||||
Our proposed implementation is certainly \textit{succinct} because it produces a signature in the format of a usual MLSAG signature, regardless of the details of the coalition. Our scheme is anonymous because all signatures are, without loss of generality, $N$-of-$N$, so each signature is fashioned with a full subset.
|
||||
|
||||
\emph{Special Thanks}: We would like to issue a special thanks to the members of the Monero community who used the GetMonero.org Forum Funding System to support the Monero Research Lab. Readers may also regard this as a statement of conflict of interest, since our funding is denominated in Monero and provided directly by members of the Monero community by the Forum Funding System.
|
||||
A natural question is to ask whether the definition of CIK can be expanded to coalition indistinguishability on keys and signatures (say CIKS) by demanding that signatures also provide no information about the signing subset or signing coalition. With an LRTM, an expansion of Definition \ref{threshIndist} to take into account an adaptive chosen message attack is nontrivial but straightforward. A CIKS LRTM scheme is necessarily succinct and anonymous according to the definition in \cite{bonehthreshold}. Moreover, a succinct and anonymous threshold signature scheme from \cite{bonehthreshold} that generates verification keys for each coalition randomly is also CIKS. In this sense, CIKS is equivalent to succinct anonymity.
|
||||
|
||||
%More importantly, \cite{bonehthreshold} presents some new definitions regarding thresholdizing cryptoschemes.
|
||||
|
||||
Additional helpful definitions appear in \cite{bonehthreshold}. For example, a threshold cryptoscheme may be regarded as \textit{private} if no subthreshold collection of key shares can reveal any information about the shared secrets, and \textit{robust} if maliciously generated evaluation key shares can always be detected. Since our implementation never reveals the shared secret key even with a threshold number of coalition members participating, our implementation is private. However, in the presence of maliciously generated choices in the signature process, we have no guarantee of robustness: although a malicious subthreshold party will only enjoy a negligible advantage in constructing a forgery, their attempt will merely appear to be an invalid signature.
|
||||
|
||||
\vspace{0.1in}
|
||||
|
||||
\textbf{Special Thanks}: We would like to issue a special thanks to the members of the Monero community who used the \texttt{GetMonero.org} Community Forum Funding System to support the Monero Research Lab. Readers may also regard this as a statement of conflict of interest, since our funding is denominated in Monero and provided directly by members of the Monero community by the Forum Funding System.
|
||||
|
||||
\medskip{}
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue