Improve security definitions for signatures.

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

protocol/protocol.tex

@@ -2423,29 +2423,30 @@ The following defines only the security properties needed for $\JoinSplitSig$.
 \crossref{abstractsigrerand}.}
 
 \securityrequirement{
-$\JoinSplitSig$\sapling{ and $\SpendAuthSig$} must be
-Strongly Unforgeable under (non-adaptive) Chosen Message Attack (SU-CMA),
-as defined for example in \cite[Definition 6]{BDEHR2011}. This allows an adversary
-to obtain signatures on chosen messages, and then requires it to be infeasible
+$\JoinSplitSig$ must be Strongly Unforgeable under (non-adaptive) Chosen Message Attack
+(SU-CMA), as defined for example in \cite[Definition 6]{BDEHR2011}. This allows an
+adversary to obtain signatures on chosen messages, and then requires it to be infeasible
 for the adversary to forge a previously unseen valid \mbox{(message, signature)}
 pair without access to the signing key.
 }
 
+\todo{Reference a different paper for the security definition. \cite{BDEHR2011} has
+a flawed security proof; this doesn't affect \Zcash but it would be better to avoid
+confusion that it might.}
+
 \begin{pnotes}
   \item A fresh signature key pair is generated for each \transaction containing
-        a \joinSplitDescription\sapling{, and for each \spendDescription}.
+        a \joinSplitDescription{}.
         Since each key pair is only used for one signature (see \crossref{nonmalleability}),
-        a one-time signature scheme would suffice for $\JoinSplitSig$\sapling{ and $\SpendAuthSig$}.
+        a one-time signature scheme would suffice for $\JoinSplitSig$.
         This is also the reason why only security against \emph{non-adaptive}
-        chosen message attack is needed.
-        In fact the instantiation of $\JoinSplitSig$
-        \sprout{uses a scheme}\sapling{and $\SpendAuthSig$ use schemes}
-        designed for security under adaptive attack even when multiple signatures
-        are signed under the same key.
+        chosen message attack is needed. In fact the instantiation of $\JoinSplitSig$
+        uses a scheme designed for security under adaptive attack even when multiple
+        signatures are signed under the same key.
   \item SU-CMA security requires it to be infeasible for the adversary, not
         knowing the private key, to forge a distinct signature on a previously
-        seen message. That is, \joinSplitSignatures\sapling{ and \spendAuthSignatures}
-        are intended to be nonmalleable in the sense of \cite{BIP-62}.
+        seen message. That is, \joinSplitSignatures are intended to be nonmalleable
+        in the sense of \cite{BIP-62}.
 \end{pnotes}
 
 
@@ -2483,12 +2484,16 @@ valid $\Sig$ key pair, then:
 
 The following security requirement for such signature schemes is based on that
 given in \cite[section 3]{FKMSSS2016}. Note that we require Strong Unforgeability
-under Re-randomized Keys, not Existential Unforgeability under Re-randomized Keys
+with Re-randomized Keys, not Existential Unforgeability with Re-randomized Keys
 (the latter is just called ``Unforgeability under Re-randomized Keys'' in
-\cite[Definition 8]{FKMSSS2016}).
+\cite[Definition 8]{FKMSSS2016}). Unlike the case for $\JoinSplitSig$, we require
+security under adaptive chosen message attack with multiple messages signed using
+a given key. (Although each \note uses a different re-randomized key pair, the same
+original key pair can be re-randomized for multiple \notes, and also it can happen
+that multiple \transactions spending the same \note are revealed to an adversary.)
 
 \introsection
-\securityrequirement{\textbf{Strong Unforgeability under Re-randomized Keys (SUFRK-CMA)}
+\securityrequirement{\textbf{Strong Unforgeability with Re-randomized Keys under adaptive Chosen Message Attack (SURK-CMA)}
 
 Let $\Oracle \typecolon \SigPrivate \times \SigMessage \times \SigRandom \rightarrow \SigSignature$
 be a generator of signing oracles.
@@ -2511,7 +2516,7 @@ $(m^*, \sigma^*) \not\in \Oracle_{\sk}\mathsf{.}Q$.
 }
 
 \begin{pnotes}
-  \item The requirement for $\SigRandomnessId$ simplifies the definition of SUFRK-CMA
+  \item The requirement for $\SigRandomnessId$ simplifies the definition of SURK-CMA
         by removing the need for two oracles (since the oracle for original keys,
         called $\Oracle_1$ in \cite{FKMSSS2016}, is a special case of the oracle for
         randomized keys).