mirror of https://github.com/zcash/zips.git
Add security argument about DiversifyHash.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
parent
5fd898adea
commit
bfc9ba5b21
|
@ -1350,6 +1350,8 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg
|
||||||
\newcommand{\vBalance}{\mathsf{v^{balance}}}
|
\newcommand{\vBalance}{\mathsf{v^{balance}}}
|
||||||
\newcommand{\vBad}{\mathsf{v^{bad}}}
|
\newcommand{\vBad}{\mathsf{v^{bad}}}
|
||||||
\newcommand{\vSum}{\mathsf{v^{*}}}
|
\newcommand{\vSum}{\mathsf{v^{*}}}
|
||||||
|
\newcommand{\OracleNewAddress}{\Oracle^{\mathsf{NewAddress}}}
|
||||||
|
\newcommand{\OracleDH}{\Oracle^{\mathsf{DH}}}
|
||||||
|
|
||||||
% Merkle tree
|
% Merkle tree
|
||||||
|
|
||||||
|
@ -5835,21 +5837,116 @@ Define
|
||||||
\securityrequirement{
|
\securityrequirement{
|
||||||
\textbf{Unlinkability:} Given two randomly selected
|
\textbf{Unlinkability:} Given two randomly selected
|
||||||
\paymentAddresses from different spend authorities, and a third \paymentAddress
|
\paymentAddresses from different spend authorities, and a third \paymentAddress
|
||||||
which could be derived from either of those authorities, it is not possible to
|
which could be derived from either of those authorities, such that the three
|
||||||
tell which authority the third address was derived from.}
|
addresses use different \diversifiers, it is not possible to tell which authority
|
||||||
|
the third address was derived from.
|
||||||
|
|
||||||
|
%\introlist
|
||||||
|
%Consider the following experiment:
|
||||||
|
%\begin{itemize}
|
||||||
|
% \item Choose two \incomingViewingKeys
|
||||||
|
% $\InViewingKey_{1,2} \leftarrowR \InViewingKeyTypeSapling$.
|
||||||
|
% \item An adversary chooses two (not necessarily distinct) \diversifiers
|
||||||
|
% $\Diversifier_{1,2} \typecolon \DiversifierType$.
|
||||||
|
% \item Define $\OracleNewAddress_i(\Diversifier' \typecolon \DiversifierType) := \begin{cases}
|
||||||
|
% \bot, &\caseif \DiversifyHash(\Diversifier') = \bot \\
|
||||||
|
% (\Diversifier', \scalarmult{\InViewingKey_i}{\DiversifyHash(\Diversifier')}), &\caseotherwise
|
||||||
|
% \end{cases}$.
|
||||||
|
% \item Define $\OracleDH_i(\EphemeralPrivate \typecolon \GF{\ParamJ{r}},
|
||||||
|
% \DiversifiedTransmitBase \typecolon \GroupJ) := \begin{cases}
|
||||||
|
% \bot, &\caseif \scalarmult{\ParamJ{h}}{\DiversifiedTransmitBase} = \ZeroJ \\
|
||||||
|
% \scalarmult{\InViewingKey_i \mult \EphemeralPrivate}{\DiversifiedTransmitBase}, &\caseotherwise
|
||||||
|
% \end{cases}$.
|
||||||
|
% \item Choose $j \leftarrowR \setof{1, 2}$.
|
||||||
|
% \item Give the adversary $\OracleNewAddress_j$ and $\OracleDH_j$.
|
||||||
|
% \item ...
|
||||||
|
%\end{itemize}
|
||||||
|
%
|
||||||
|
%The adversary wins if it returns $j$ with probability significantly greater than $0.5$
|
||||||
|
%(i.e.\ than chance), over choices of ....
|
||||||
|
|
||||||
|
%% the experiment must capture Brian Warner's attack
|
||||||
|
} %securityrequirement
|
||||||
|
|
||||||
\begin{nnotes}
|
\begin{nnotes}
|
||||||
\item Suppose that $\GroupJHash{}$ (restricted to inputs for which it does not
|
\item Suppose that $\GroupJHash{}$ (restricted to inputs for which it does not
|
||||||
return $\bot$) is modelled as a random oracle from \diversifiers to points
|
return $\bot$) is modelled as a random oracle from \diversifiers to points
|
||||||
of order $\ParamJ{r}$ on the \jubjubCurve. In this model, Unlinkability
|
of order $\ParamJ{r}$ on the \jubjubCurve. In this model, Unlinkability
|
||||||
of $\DiversifyHash$ holds under the Decisional Diffie-Hellman assumption on the
|
of $\DiversifyHash$ holds under the Decisional Diffie-Hellman assumption on the
|
||||||
\jubjubCurve.
|
prime-order subgroup of the \jubjubCurve.
|
||||||
|
|
||||||
|
To prove this, consider the ElGamal encryption scheme \cite{ElGamal1985}
|
||||||
|
on this prime-order subgroup, restricted to encrypting plaintexts encoded
|
||||||
|
as the group identity $\ZeroJ$. (ElGamal was originally defined for $\GFstar{p}$
|
||||||
|
but works in any prime-order group.) ElGamal public keys then have the same form
|
||||||
|
as \diversifiedPaymentAddresses. If we make the assumption above on $\GroupJHash{}$,
|
||||||
|
then generating a new \diversifiedPaymentAddress from a given address $\pk$,
|
||||||
|
gives the same distribution of
|
||||||
|
$(\DiversifiedTransmitBase', \DiversifiedTransmitPublic')$ pairs as the
|
||||||
|
distribution of ElGamal ciphertexts obtained by encrypting $\ZeroJ$ under $\pk$.
|
||||||
|
\todo{check whether this is justified.}
|
||||||
|
Then, the definition of \keyPrivacy (IK-CPA as defined in \cite[Definition 1]{BBDP2001})
|
||||||
|
for ElGamal corresponds to the definition of Unlinkability for $\DiversifyHash$.
|
||||||
|
(IK-CCA corresponds to the potentially stronger requirement that $\DiversifyHash$
|
||||||
|
remains Unlinkable when given Diffie-Hellman key agreement oracles for each
|
||||||
|
of the candidate \diversifiedPaymentAddresses.)
|
||||||
|
So if ElGamal is \keyPrivate, then $\DiversifyHash$ is Unlinkable under the
|
||||||
|
same conditions.
|
||||||
|
\cite[Appendix A]{BBDP2001} gives a security proof for \keyPrivacy
|
||||||
|
(both IK-CPA and IK-CCA) of ElGamal under the Decisional Diffie-Hellman
|
||||||
|
assumption on the relevant group. (In fact the proof needed is the
|
||||||
|
``small modification'' described in the last paragraph in which the generator
|
||||||
|
is chosen at random for each key.)
|
||||||
|
|
||||||
|
\item It is assumed (also for the security of other uses of
|
||||||
|
the group hash, such as Pedersen hashes and commitments) that the discrete
|
||||||
|
logarithm of the output group element with respect to any other generator
|
||||||
|
is unknown. This assumption is justified if the group hash acts as a
|
||||||
|
random oracle.
|
||||||
|
Essentially, \diversifiers act as handles to unknown random numbers.
|
||||||
|
(The group hash inputs used with different personalizations are in different
|
||||||
|
``namespaces''.)
|
||||||
|
|
||||||
\item Informally, the random self-reducibility property of DDH implies that an
|
\item Informally, the random self-reducibility property of DDH implies that an
|
||||||
adversary would gain no advantage from being able to query an oracle for
|
adversary would gain no advantage from being able to query an oracle for
|
||||||
additional $(\DiversifiedTransmitBase, \DiversifiedTransmitPublic)$ pairs
|
additional $(\DiversifiedTransmitBase, \DiversifiedTransmitPublic)$ pairs
|
||||||
with the same spend authority as an existing \paymentAddress, since they
|
with the same spend authority as an existing \paymentAddress, since they
|
||||||
could also create such pairs on their own. This justifies only considering
|
could also create such pairs on their own. This justifies only considering
|
||||||
two \paymentAddresses in the security definition.
|
two \paymentAddresses in the security definition.
|
||||||
|
|
||||||
|
\todo{FIXME This is not correct, because additional pairs don't quite
|
||||||
|
follow the same distribution as an address with a valid diversifier.
|
||||||
|
The security definition may need to be more complex to model this properly.}
|
||||||
|
|
||||||
|
% \item The restriction that an adversary may not query the ``new address'' oracle
|
||||||
|
% with a .. corresponds to the requirement that a .. not reuse diversifiers
|
||||||
|
% for a given \incomingViewingKey. If this requirement is not met then the
|
||||||
|
% adversary can trivially break Unlinkability. Of course, it is not desirable
|
||||||
|
% to provide ``new address'' or Diffie-Hellman oracles at all in a real
|
||||||
|
% implementation; the oracles are included in the security definition merely in
|
||||||
|
% order to prove the strongest possible security property.
|
||||||
|
|
||||||
|
\item An $88$-bit diversifier cannot be considered cryptographically unguessable
|
||||||
|
at a $128$-bit security level; also, randomly chosen diversifiers are likely
|
||||||
|
to suffer birthday collisions when the number of choices approaches $2^{44}$.
|
||||||
|
|
||||||
|
If most users are choosing diversifiers randomly (as recommended in
|
||||||
|
\crossref{saplingkeycomponents}), then the fact that they
|
||||||
|
may accidentally choose diversifiers that collide (and therefore reveal
|
||||||
|
the fact that they are not derived from the same \incomingViewingKey)
|
||||||
|
does not appreciably reduce the anonymity set.
|
||||||
|
|
||||||
|
In \cite{ZIP-32} an $88$-bit \pseudoRandomPermutation, keyed differently for
|
||||||
|
each node of the derivation tree, is used to select new \diversifiers.
|
||||||
|
This resolves the potential problem, provided that the input to the
|
||||||
|
\pseudoRandomPermutation does not repeat for a given node.
|
||||||
|
|
||||||
|
\item If the holder of an \incomingViewingKey permits an adversary to ask for a new
|
||||||
|
address for that \incomingViewingKey with a given \diversifier, then it can
|
||||||
|
trivially break Unlinkability for the other \diversifiedPaymentAddresses
|
||||||
|
associated with the \incomingViewingKey (this does not compromise other
|
||||||
|
privacy properties). Implementations \SHOULD avoid providing such a
|
||||||
|
``chosen \diversifier'' oracle.
|
||||||
\end{nnotes}
|
\end{nnotes}
|
||||||
} %sapling
|
} %sapling
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue