Update specification of Poseidon.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>

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}.

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