zec
/
zips
mirror of https://github.com/zcash/zips.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Remove GeneralCRH in favour of specifying hSigCRH and EquihashGen directly in terms of BLAKE2b. 

Correct the security requirement for EquihashGen.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
Daira Hopwood 2016-09-11 01:14:03 +01:00
parent b000393347
commit d78b13f767
1 changed files with 49 additions and 37 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

86
protocol/protocol.tex
View File

@ -289,7 +289,6 @@
\newcommand{\hSigCRH}{\mathsf{hSigCRH}} \newcommand{\hSigCRH}{\mathsf{hSigCRH}}
\newcommand{\hSigLength}{\mathsf{\ell_{hSig}}} \newcommand{\hSigLength}{\mathsf{\ell_{hSig}}}
\newcommand{\hSigType}{\bitseq{\hSigLength}} \newcommand{\hSigType}{\bitseq{\hSigLength}}
\newcommand{\GeneralCRH}[1]{\mathsf{GeneralCRH}_{#1}}
\newcommand{\EquihashGen}[1]{\mathsf{EquihashGen}_{#1}} \newcommand{\EquihashGen}[1]{\mathsf{EquihashGen}_{#1}}
\newcommand{\CRH}{\mathsf{CRH}} \newcommand{\CRH}{\mathsf{CRH}}
\newcommand{\CRHbox}[1]{\SHA\left(\Justthebox{#1}\right)} \newcommand{\CRHbox}[1]{\SHA\left(\Justthebox{#1}\right)}
@ -1884,21 +1883,18 @@ such that $\SHA(x) = \zeros{256}$.
$\hSigCRH$ is used to compute the value $\hSig$ in \crossref{joinsplitdesc}. $\hSigCRH$ is used to compute the value $\hSig$ in \crossref{joinsplitdesc}.
\changed{ \changed{
\hskip 1.5em $\hSigCRH(\RandomSeed, \nfOld{\allOld}, \joinSplitPubKey) := \GeneralCRH{256}(\ascii{ZcashComputehSig},\; \hSigInput)$ \hskip 1.5em $\hSigCRH(\RandomSeed, \nfOld{\allOld}, \joinSplitPubKey) := \Blake{256}(\ascii{ZcashComputehSig},\; \hSigInput)$
where where
\hskip 1.5em $\hSigInput := \Justthebox{\hsigbox}$. \hskip 1.5em $\hSigInput := \Justthebox{\hsigbox}$.
} }
$\GeneralCRH{\ell}(p, x)$ is instantiated by unkeyed $\Blake{\ell}$ $\Blake{256}(p, x)$ refers to unkeyed $\Blake{256}$
\cite{ANWW2013}\cite{RFC-7693} in sequential mode, with an output \cite{ANWW2013}\cite{RFC-7693} in sequential mode, with an output
digest length of $\ell/8$ bytes, 16-byte personalization string $p$, digest length of $32$ bytes, 16-byte personalization string $p$,
and input $x$. and input $x$. This is not the same as $\Blake{512}$ truncated to
$256$ bits.
\pnote{
$\Blake{\ell}$ is not the same as $\Blake{512}$ truncated to $\ell$ bits.
}
\securityrequirement{ \securityrequirement{
$\Blake{256}(\ascii{ZcashComputehSig}, x)$ must be collision-resistant. $\Blake{256}(\ascii{ZcashComputehSig}, x)$ must be collision-resistant.
@ -1935,15 +1931,27 @@ Let $\EquihashGen{n, k}(S, i) := T_{h+1\hairspace..\hairspace h+n}$, where
\begin{itemize} \begin{itemize}
\item $m := \floor{\frac{512}{n}}$; \item $m := \floor{\frac{512}{n}}$;
\item $h := (i-1 \bmod m)\, n$; \item $h := (i-1 \bmod m)\, n$;
\item $T := \GeneralCRH{n m}(\powtag,\, S \,||\, \powcount(\floor{\frac{i-1}{m}}))$. \item $T := \Blake{(n m)}(\powtag,\, S \,||\, \powcount(\floor{\frac{i-1}{m}}))$.
\end{itemize} \end{itemize}
Indices of bits in $T$ are 1-based. $\GeneralCRH{\ell}(p, x)$ is defined Indices of bits in $T$ are 1-based.
as in the previous section.
$\Blake{\ell}(p, x)$ refers to unkeyed $\Blake{\ell}$
\cite{ANWW2013}\cite{RFC-7693} in sequential mode, with an output
digest length of $\ell/8$ bytes, 16-byte personalization string $p$,
and input $x$. This is not the same as $\Blake{512}$ truncated to
$\ell$ bits.
\securityrequirement{ \securityrequirement{
$\Blake{\ell}(\powtag, x)$ must be collision-resistant, for any $\ell$ and $\Blake{\ell}(\powtag, x)$ must generate output that is sufficiently
$\powtag$ used in the protocol. unpredictable to avoid short-cuts to the Equihash solution process.
It would suffice to model it as a random oracle.
}
\pnote{
When $\EquihashGen{}$ is evaluated for sequential indices (as in \crossref{equihash}),
the number of calls to $\BlakeGeneric$ can be reduced by a factor of $\floor{\frac{512}{n}}$
in the best case (which is a factor of 2 for $n = 200$).
} }
\nsubsubsection{\PseudoRandomFunctions} \label{concreteprfs} \nsubsubsection{\PseudoRandomFunctions} \label{concreteprfs}
@ -2838,21 +2846,16 @@ then the corresponding bit array is:
and so the first 7 bytes of $\nSolution$ would be and so the first 7 bytes of $\nSolution$ would be
$[0, 2, 32, 0, 10, 127, 255]$. $[0, 2, 32, 0, 10, 127, 255]$.
\begin{pnotes} \pnote{
\item $\ItoBSP{}$ and $\BStoIP{}$ are big-endian, while the encoding of $\ItoBSP{}$ and $\BStoIP{}$ are big-endian, while the encoding of
integer fields in $\powheader$ and in the instantiation of $\EquihashGen{}$ integer fields in $\powheader$ and in the instantiation of $\EquihashGen{}$
is little-endian. The rationale for this is that little-endian is little-endian. The rationale for this is that little-endian
serialization of \blockHeaders is consistent with \Bitcoin, but using serialization of \blockHeaders is consistent with \Bitcoin, but using
little-endian ordering of bits in the solution encoding would require little-endian ordering of bits in the solution encoding would require
bit-reversal (as opposed to only shifting). The comparison of $\Xi_r$ bit-reversal (as opposed to only shifting). The comparison of $\Xi_r$
values obtained by a big-endian conversion is equivalent to lexicographic values obtained by a big-endian conversion is equivalent to lexicographic
comparison as specified in \cite[section IV A]{BK2016}. comparison as specified in \cite[section IV A]{BK2016}.
\item When $\EquihashGen{}$ is used to construct the input list, the index }
$i$ runs sequentially from $1$ to $N$, allowing the number of calls
to $\BlakeGeneric$ used in the instantiation of $\EquihashGen{}$ to
be reduced by a factor of $\floor{\frac{512}{n}}$ (which is a factor
of 2 for $n = 200$).
\end{pnotes}
\nsubsubsection{Difficulty filter} \label{difficulty} \nsubsubsection{Difficulty filter} \label{difficulty}
@ -2993,9 +2996,9 @@ for each $\NoteAddressRand$, by making use of the fact that all of the
\nullifiers in \joinSplitDescriptions that appear in a valid \blockchainview \nullifiers in \joinSplitDescriptions that appear in a valid \blockchainview
must be distinct. This is true regardless of whether the \nullifiers must be distinct. This is true regardless of whether the \nullifiers
corresponded to real or dummy notes (see \crossref{dummynotes}). corresponded to real or dummy notes (see \crossref{dummynotes}).
The \nullifiers are used as input to $\Blake{256}$ The \nullifiers are used as input to $\hSigCRH$ to derive a public value
to derive a public value $\hSig$ which uniquely identifies the transaction, $\hSig$ which uniquely identifies the transaction, as described in
as described in \crossref{joinsplitdesc}. ($\hSig$ was already used in \Zerocash \crossref{joinsplitdesc}. ($\hSig$ was already used in \Zerocash
in a way that requires it to be unique in order to maintain in a way that requires it to be unique in order to maintain
indistinguishability of \joinSplitDescriptions; adding the \nullifiers indistinguishability of \joinSplitDescriptions; adding the \nullifiers
to the input of the hash used to calculate it has the effect of making to the input of the hash used to calculate it has the effect of making
@ -3010,7 +3013,7 @@ $\NoteAddressRand$ for each output \note is enforced by the \joinSplitStatement
Now even if the creator of a \joinSplitDescription does not choose Now even if the creator of a \joinSplitDescription does not choose
$\NoteAddressPreRand$ randomly, uniqueness of \nullifiers and $\NoteAddressPreRand$ randomly, uniqueness of \nullifiers and
collision resistance of both $\Blake{256}$ and $\PRFrho{}$ will ensure collision resistance of both $\hSigCRH$ and $\PRFrho{}$ will ensure
that the derived $\NoteAddressRand$ values are unique, at least for that the derived $\NoteAddressRand$ values are unique, at least for
any two \joinSplitDescriptions that get into a valid \blockchainview. any two \joinSplitDescriptions that get into a valid \blockchainview.
This is sufficient to prevent the Faerie Gold attack. This is sufficient to prevent the Faerie Gold attack.
@ -3101,11 +3104,12 @@ twice.
For resistance to Faerie Gold attacks as described in For resistance to Faerie Gold attacks as described in
\crossref{faeriegold}, \Zcash depends on collision resistance of both \crossref{faeriegold}, \Zcash depends on collision resistance of both
$\GeneralCRH{256}$ and $\PRFrho{}$. Collision resistance of a truncated hash $\hSigCRH$ and $\PRFrho{}$ (instantiated using $\Blake{256}$ and $\SHA$
respectively). Collision resistance of a truncated hash
does not follow from collision resistance of the original hash, even if the does not follow from collision resistance of the original hash, even if the
truncation is only by one bit. This motivated instantiating $\GeneralCRH{\ell}$ truncation is only by one bit. This motivated avoiding truncation along any
as $\Blake{\ell}$ in \Zcash, and avoiding truncation along any path from the path from the inputs to the computation of $\hSig$ to the uses of
inputs to the computation of $\hSig$ to the uses of $\NoteAddressRand$. $\NoteAddressRand$.
Since the PRFs are instantiated using $\SHA$ which has an input block Since the PRFs are instantiated using $\SHA$ which has an input block
size of 512 bits (of which 256 bits are used for the PRF input and 4 bits size of 512 bits (of which 256 bits are used for the PRF input and 4 bits
@ -3276,6 +3280,14 @@ The errors in the proof of Ledger Indistinguishability mentioned in
\nsection{Change history} \nsection{Change history}
\subparagraph{2016.0-beta-1.2}
\begin{itemize}
\item Remove $\mathsf{GeneralCRH}$ in favour of specifying $\hSigCRH$ and
$\EquihashGen{}$ directly in terms of $\BlakeGeneric$.
\item Correct the security requirement for $\EquihashGen{}$.
\end{itemize}
\subparagraph{2016.0-beta-1.1} \subparagraph{2016.0-beta-1.1}
\begin{itemize} \begin{itemize}