From bbc6131f2979382edddadee2430fbb7467642b7c Mon Sep 17 00:00:00 2001 From: Daira Hopwood Date: Fri, 26 Mar 2021 17:28:06 +0000 Subject: [PATCH] Update specification of Poseidon. Signed-off-by: Daira Hopwood --- protocol/protocol.tex | 33 +++++++++++++++++++++------------ protocol/zcash.bib | 19 +++++++++++++++++++ 2 files changed, 40 insertions(+), 12 deletions(-) diff --git a/protocol/protocol.tex b/protocol/protocol.tex index bc61f62e..1fdb1787 100644 --- a/protocol/protocol.tex +++ b/protocol/protocol.tex @@ -8534,6 +8534,10 @@ inside a circuit. $\Poseidon$ is a cryptographic permutation described in \cite{GKRRS2019}. It operates over a sequence of finite field elements, which we instantiate as $\typeexp{\GF{\ParamP{q}}}{3}$. +The following specification is intended to follow \cite{GKRRS2019} and Version 1.1 of the $\Poseidon$ +reference implementation \cite{Poseidon-1.1}.\footnote{\nufive{Previous versions of the reference implementation +were inconsistent with the paper.}} + The S-box function is $x \mapsto x^5$. The number of full rounds $R_F$ is $8$, and the number of partial rounds $R_P$ is $58$. @@ -8541,8 +8545,9 @@ We use $\Poseidon$ in a sponge configuration \cite{BDPA2011} (with elementwise a $\GF{\ParamP{q}}$ replacing exclusive-or of bit strings\footnote{\nufive{The sponge construction was originally proposed as operating on an arbitrary group. \cite{BDPA2007}}}) to construct a \hashFunction. The sponge capacity is one field element, the rate is two field elements, and -the output is one field element. We do not append any padding to the input message; this does -not affect security because the input length is fixed. +the output is one field element. We use the ``Constant-Input-Length''\strut mode described in +\cite[section 4.2]{GKRRS2019}: for a $2$-element input, the initial value of the capacity +element is $2^{65}$, and no padding of the input message is needed. That is, if $f \typecolon \typeexp{\GF{\ParamP{q}}}{3} \rightarrow \typeexp{\GF{\ParamP{q}}}{3}$ is the $\Poseidon$ permutation, then the \hashFunction @@ -8553,11 +8558,13 @@ is specified as: \item $\PoseidonHash(x, y) = f([x, y, 2^{65}])_1$ (using $1$-based indexing). \end{formulae} -\todo{Specify the MDS matrix.} +The MDS matrix is as generated by \texttt{generate\_parameters\_grain.sage} in Version 1.1 of the +reference implementation. \begin{nnotes} \item The choice of MDS matrix and the number of rounds take into account cryptanalytic - results in \cite{KR2020} and \cite{BCD+2020}. \todo{check.} + results in \cite{KR2020} and \cite{BCD+2020}. A detailed analysis of related matrix + properties is given in \cite{GRS2020}. \item \cite{BCD+2020} says that ``... finite fields $\mathbb{F}_q$ with a limited number of multiplicative subgroups might be preferable, i.e.\ one might want to avoid $q-1$ being smooth. This implies that the fields which are @@ -8565,8 +8572,8 @@ is specified as: $\GF{\ParamP{q}}$ is such a field; the factorization of $\ParamP{q}-1$ is $2^{32} \mult 3 \mult 463 \mult 539204044132271846773 \mult 8999194758858563409123804352480028797519453$. - Furthermore, cryptanalysis of $\Poseidon$ has focussed mainly on the case of S-box - $x \mapsto x^3$. That variant cannot be used in $\GF{\ParamP{q}}$ because + Furthermore, previous cryptanalysis of $\Poseidon$ has focussed mainly on the case + of S-box $x \mapsto x^3$. That variant cannot be used in $\GF{\ParamP{q}}$ because $x \mapsto x^3$ would not be a permutation. $\alpha = 5$ is the smallest integer for which $x \mapsto x^\alpha$ is a permutation in $\GF{\ParamP{q}}$. @@ -8581,19 +8588,20 @@ is specified as: sponge mode limits an adversary to only being able to influence part of the $\Poseidon$ permutation input, and we use it only to construct a PRF ($\PRFnf{Orchard}{}$ as described in \crossref{concreteprfs}). Half of the sponge input is a random key $\NullifierKey$, - known only to holders of a \fullViewingKey, and the remaining half $\NoteUniqueRandRepr$ - is also chosen randomly by the \note creator (both are derived using $\PRFexpand{}$, - from $\SpendingKey$ and $\NoteSeedBytes$ respectively). Then the PRF is used to enhance - the security of a discrete-log-based nullifier construction (described in \crossref{...}) + known only to holders of a \fullViewingKey, and the remaining half $\NoteUniqueRand$ + comes from a previous \nullifier which is effectively a random $x$-coordinate on the + \pallasCurve. Then the PRF is used to enhance the security of a discrete-logarithm-based + nullifier construction (described in \cite[Section 3.5 Nullifiers]{Zcash-Orchard}) against a potential discrete-log-breaking adversary. Given the weak assumption that the $\PoseidonHash$ sponge produces output that preserves sufficient entropy - from the inputs $\NullifierKey$ and $\NoteUniqueRandRepr$, this nullifier + from the inputs $\NullifierKey$ and $\NoteUniqueRand$, this nullifier construction would still be secure under a decisional Diffie--Hellman assumption on the \Pallas curve, even if the $\Poseidon$-based PRF were distinguishable from an ideal PRF. The recommended number of partial rounds for these parameters in the Poseidon paper - is $57$, but we prefer an even number of partial rounds for circuit efficiency. + is $57$, but we prefer an even number of partial rounds to simplify the circuit + implementation. \item The constant $2^{65}$ comes from \cite[section 4.2]{GKRRS2019}: ``Constant-Input-Length Hashing. The capacity value is $\mathit{length} \mult (2^{64}) + (o - 1)$ where $o$ is the output length.'' In this case the input length ($\mathit{length}$) is @@ -13987,6 +13995,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}. between the protocol specification and \cite{ZIP-225}. \item Make the naming of $\enableSpends$ and $\enableOutputs$ consistent. \end{itemize} + \item Update specification of $\Poseidon$. \item Add references to \cite{Zcash-halo2}. \item Correct the description of $\lengthField$ in \crossref{unifiedpaymentaddrencoding}. \item Correct the type signature of $\DiversifyHash{Orchard}$ in \crossref{abstracthashes}. diff --git a/protocol/zcash.bib b/protocol/zcash.bib index 8f041922..2a93dd60 100644 --- a/protocol/zcash.bib +++ b/protocol/zcash.bib @@ -501,6 +501,15 @@ Received March~20, 2012.} Last updated December~16, 2020.} } +@misc{Poseidon-1.1, + presort={Poseidon-1.1}, + author={Lorenzo Grassi and Dmitry Khovratovich and Christian Rechberger and Arnab Roy and Markus Schofnegger}, + title={Poseidon reference implementation, Version 1.1}, + date={2021-03-07}, + url={https://extgit.iaik.tugraz.at/krypto/hadeshash/-/commit/7ecf9a7d4f37e777ea27e4c4d379443151270563}, + urldate={2021-03-23} +} + @misc{BDPA2007, presort={BDPA2007}, author={Guido Bertoni and Joan Daemen and Michaël Peeters and Gilles {Van Assche}}, @@ -600,6 +609,16 @@ Last revised November~11, 2020.}, Lecture Notes in Computer Science; Springer, 2020.} } +@misc{GRS2020, + presort={GRS2020}, + author={Lorenzo Grassi and Christian Rechberger and Markus Schofnegger}, + title={Proving Resistance Against Infinitely Long Subspace Trails: {H}ow to Choose the Linear Layer}, + url={https://eprint.iacr.org/2020/500}, + urldate={2021-03-23}, + howpublished={Cryptology ePrint Archive: Report 2020/500. +Last revised January~27, 2021.} +} + @misc{AGRRT2017, presort={AGRRT2017}, author={Martin Albrecht and Lorenzo Grassi and Christian Rechberger and