Protocol spec: add some index macros.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
Daira Hopwood 2019-07-23 13:06:44 +01:00
parent 8e52e03761
commit 9ac2beeed8
1 changed files with 153 additions and 135 deletions

View File

@ -620,9 +620,14 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg
\newcommand{\MAY}{\conformance{MAY}}
\newcommand{\ALLCAPS}{\conformance{ALL CAPS}}
\newcommand{\collisionResistant}{collision\hyp resistant }
\newcommand{\collisionResistance}{collision resistance }
\newcommand{\collisionResistant}{\termandindex{collision\hyp resistant}{collision resistance}}
\newcommand{\collisionResistance}{\term{collision resistance}}
\newcommand{\xCollisionResistance}{\termx{collision resistance}}
\newcommand{\publicKey}{\term{public key}}
\newcommand{\publicKeys}{\terms{public key}}
\newcommand{\privateKey}{\term{private key}}
\newcommand{\privateKeys}{\terms{private key}}
\newcommand{\keyPrivacy}{\term{key privacy}}
\newcommand{\xKeyPrivacy}{\termx{key privacy}}
\newcommand{\keyPrivate}{\termandindex{key\hyp private}{key privacy}}
@ -638,7 +643,8 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg
\newcommand{\commitmentSchemes}{\terms{commitment scheme}}
\newcommand{\commitmentTrapdoor}{\term{commitment trapdoor}}
\newcommand{\commitmentTrapdoors}{\terms{commitment trapdoor}}
\newcommand{\trapdoor}{\termandindex{trapdoor}{trapdoor (of a commitment)}}
\newcommand{\trapdoor}{\termandindex{trapdoor}{commitment trapdoor}}
\newcommand{\trapdoors}{\termandindex{trapdoors}{commitment trapdoor}}
\newcommand{\noteCommitment}{\term{note commitment}}
\newcommand{\noteCommitments}{\terms{note commitment}}
\newcommand{\xNoteCommitments}{\termxs{note commitment}}
@ -769,8 +775,21 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg
\newcommand{\Jubjub}{\titleterm{Jubjub}}
\newcommand{\completeTwistedEdwardsEllipticCurve}{\term{complete twisted Edwards elliptic curve}}
\newcommand{\completeTwistedEdwardsEllipticCurves}{\terms{complete twisted Edwards elliptic curve}}
\newcommand{\xCtEdwards}{\term{ctEdwards}}
\newcommand{\ctEdwardsCurve}{\termandindex{ctEdwards curve}{complete twisted Edwards elliptic curve}}
\newcommand{\ctEdwardsCurves}{\termandindex{ctEdwards curves}{complete twisted Edwards elliptic curve}}
\newcommand{\ctEdwardsCompressedEncoding}{\termandindex{ctEdwards compressed encoding}{complete twisted Edwards compressed encoding}}
\newcommand{\ctEdwardsCompressedEncodings}{\termandindex{ctEdwards compressed encodings}{complete twisted Edwards compressed encoding}}
\newcommand{\affineCtEdwards}{\termandindex{affine-ctEdwards}{complete twisted Edwards affine coordinates}}
\newcommand{\xAffineCtEdwards}{\termandindex{Affine-ctEdwards}{complete twisted Edwards affine coordinates}}
\newcommand{\AffineCtEdwards}{\titleterm{Affine-ctEdwards}}
\newcommand{\MontgomeryEllipticCurve}{\term{Montgomery elliptic curve}}
\newcommand{\MontgomeryEllipticCurves}{\terms{Montgomery elliptic curve}}
\newcommand{\MontgomeryCurve}{\termandindex{Montgomery curve}{Montgomery elliptic curve}}
\newcommand{\MontgomeryCurves}{\termandindex{Montgomery curves}{Montgomery elliptic curve}}
\newcommand{\affineMontgomery}{\termandindex{affine-Montgomery}{Montgomery affine coordinates}}
\newcommand{\xAffineMontgomery}{\termandindex{Affine-Montgomery}{Montgomery affine coordinates}}
\newcommand{\AffineMontgomery}{\titleterm{Affine-Montgomery}}
\newcommand{\uniformRandomString}{\term{Uniform Random String}}
\newcommand{\uniformRandomStrings}{\terms{Uniform Random String}}
\newcommand{\BNRepresentedPairing}{\titleterm{BN-254}}
@ -794,6 +813,7 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg
\newcommand{\fullValidator}{\term{full validator}}
\newcommand{\fullValidators}{\terms{full validator}}
\newcommand{\consensusRuleChange}{\term{consensus rule change}}
\newcommand{\networkUpgrade}{\term{network upgrade}}
\newcommand{\anchor}{\term{anchor}}
\newcommand{\anchors}{\terms{anchor}}
\newcommand{\block}{\term{block}}
@ -1928,8 +1948,6 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg
% Consensus rules
\newcommand{\networkUpgrade}{\term{network upgrade}}
\newcommand{\consensusrule}[1]{\needspace{4ex}\vspace{2ex}\callout{}{Consensus rule:}{#1}}
\newenvironment{consensusrules}{\introlist\callout{}{Consensus rules:}\begin{itemize}}{\end{itemize}}
\newcommand{\sproutspecificitem}[1]{\item \sproutspecific{#1}}
@ -2129,7 +2147,7 @@ were called \definingquotedterm{serial numbers}.},
which specify an amount and \sprout{a \payingKey. The \payingKey is part of}
\notsprout{(indirectly)}
a \paymentAddress, which is a destination to which \notes can be sent.
As in \Bitcoin, this is associated with a private key that can be used to
As in \Bitcoin, this is associated with a \privateKey that can be used to
spend \notes sent to the address; in \Zcash this is called a \spendingKey.
To each \note there is cryptographically associated a \noteCommitment. Once the
@ -2180,7 +2198,7 @@ which proves that all of the following hold except with insignificant probabilit
\item The private \spendingKeys of the input \notes are cryptographically
linked to a signature over the whole \transaction, in such a way that
the \transaction cannot be modified by a party who did not know these
private keys.
\privateKeys.
\item Each output \note is generated in such a way that it is infeasible to
cause its \nullifier to collide with the \nullifier of any other \note.
\end{itemize}
@ -2222,11 +2240,11 @@ Outside the \zkSNARK, it is \sprout{also} checked that the \nullifiers for the i
\notes had not already been revealed (i.e.\ they had not already been spent).
A \paymentAddress includes
\sprout{two public keys: a \payingKey matching that of \notes sent to the address, and }a
\sprout{two \publicKeys: a \payingKey matching that of \notes sent to the address, and }a
\transmissionKey for a ``\keyPrivate'' asymmetric encryption
scheme. \mbox{\xKeyPrivate} means that ciphertexts do not reveal information
about which key they were encrypted to, except to a holder of the corresponding
private key, which in this context is called the \receivingKey. This facility is
\privateKey, which in this context is called the \receivingKey. This facility is
used to communicate encrypted output \notes on the \blockchain to their
intended recipient, who can use the \receivingKey to scan the \blockchain for
\notes addressed to them and then decrypt those \notes.
@ -2479,7 +2497,7 @@ and rational constants $\FoundersFraction$, $\PoWMaxAdjustDown$, and
$\PoWMaxAdjustUp$ will also be defined in that section.
\notsprout{
We use the abbreviation ``ctEdwards'' to refer to \completeTwistedEdwardsEllipticCurves and
We use the abbreviation ``\defining{\xCtEdwards}'' to refer to \completeTwistedEdwardsEllipticCurves and
coordinates (see \crossref{jubjub}).
}
@ -2548,8 +2566,8 @@ of scanning the \blockchain for relevant \transactions.
\vspace{-1ex}
\pnote{
It is conventional in cryptography to refer to the key used to encrypt
a message in an asymmetric encryption scheme as the \definingquotedterm{public key}.
However, the public key used as \defining{the \transmissionKey component of an address
a message in an asymmetric encryption scheme as the ``\defining{\publicKey}''.
However, the \publicKey used as \defining{the \transmissionKey component of an address
($\TransmitPublic$\sapling{ or $\DiversifiedTransmitPublic$})} need not be
publically distributed; it has the same distribution as the \paymentAddress itself.
As mentioned above, limiting the distribution of the \paymentAddress is important
@ -3157,18 +3175,18 @@ may make many adaptive chosen ciphertext queries for a given key.
\lsubsubsection{\KeyAgreement}{abstractkeyagreement}
A \defining{\keyAgreementScheme} is a cryptographic protocol in which two parties agree
a shared secret, each using their private key and the other party's public key.
a shared secret, each using their \privateKey and the other party's \publicKey.
A \keyAgreementScheme $\KA$ defines a type of public keys $\KAPublic$, a type
of private keys $\KAPrivate$, and a type of shared secrets $\KASharedSecret$.
A \keyAgreementScheme $\KA$ defines a type of \publicKeys $\KAPublic$, a type
of \privateKeys $\KAPrivate$, and a type of shared secrets $\KASharedSecret$.
\sapling{Optionally, it also defines a type $\KAPublicPrimeOrder \subseteq \KAPublic$.}
\sapling{Optional:} Let $\KAFormatPrivate \typecolon \PRFOutputSprout \rightarrow \KAPrivate$
be a function to convert a bit string of length $\PRFOutputLengthSprout$ to a $\KA$ private key.
be a function to convert a bit string of length $\PRFOutputLengthSprout$ to a $\KA$ \privateKey.
Let $\KADerivePublic \typecolon \KAPrivate \times \KAPublic \rightarrow \KAPublic$
be a function that derives the $\KA$ public key corresponding to a given $\KA$
private key and base point.
be a function that derives the $\KA$ \publicKey corresponding to a given $\KA$
\privateKey and base point.
Let $\KAAgree \typecolon \KAPrivate \times \KAPublic \rightarrow \KASharedSecret$
be the agreement function.
@ -3179,7 +3197,7 @@ be the agreement function.
\begin{securityrequirements}
\item $\KAFormatPrivate$ must preserve sufficient entropy from its input to be used
as a secure $\KA$ private key.
as a secure $\KA$ \privateKey.
\item The key agreement and the KDF defined in the next section must together
satisfy a suitable adaptive security assumption along the lines of
\cite[section 3]{Bernstein2006} or \cite[Definition 3]{ABR1999}.
@ -3243,7 +3261,7 @@ The inputs to the \keyDerivationFunction differ between the \Sprout and
$\KDFSprout$ takes as input an output index in $\setofNew$, the
value $\hSig$, the shared Diffie-Hellman secret $\DHSecret{}$,
the ephemeral public key $\EphemeralPublic$, and the recipient's
the ephemeral \publicKey $\EphemeralPublic$, and the recipient's
public \transmissionKey $\TransmitPublic$. It is suitable for use
with $\KASprout$ and derives keys for $\SymEncrypt{}$.
@ -3254,7 +3272,7 @@ with $\KASprout$ and derives keys for $\SymEncrypt{}$.
\sapling{
$\KDFSapling$ takes as input the shared Diffie-Hellman secret $\DHSecret{}$ and
the ephemeral public key $\EphemeralPublic$. (It does not have inputs taking the
the ephemeral \publicKey $\EphemeralPublic$. (It does not have inputs taking the
place of the output index, $\hSig$, or $\TransmitPublic$.) It is suitable for use
with $\KASapling$ and derives keys for $\SymEncrypt{}$.
@ -3360,7 +3378,7 @@ pair without access to the signing key.
in the same distribution as of freshly generated key pairs, for each
\transaction containing \spendDescriptions or \outputDescriptions{}.}
\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
knowing the \privateKey, to forge a distinct signature on a previously
seen message. That is, \joinSplitSignatures\sapling{ and \bindingSignatures}
are intended to be \defining{\sigNonmalleable} in the sense of \cite{BIP-62}.
\end{nnotes}
@ -3376,8 +3394,8 @@ additionally defines:
\begin{itemize}
\item a type of randomizers $\SigRandom$;
\item a randomizer generator $\SigGenRandom \typecolon () \rightarrowR \SigRandom$;
\item a private key randomization algorithm $\SigRandomizePrivate \typecolon \SigRandom \times \SigPrivate \rightarrow \SigPrivate$;
\item a public key randomization algorithm $\SigRandomizePublic \typecolon \SigRandom \times \SigPublic \rightarrow \SigPublic$;
\item a \privateKey randomization algorithm $\SigRandomizePrivate \typecolon \SigRandom \times \SigPrivate \rightarrow \SigPrivate$;
\item a \publicKey randomization algorithm $\SigRandomizePublic \typecolon \SigRandom \times \SigPublic \rightarrow \SigPublic$;
\item a distinguished ``identity'' randomizer $\SigRandomizerId \typecolon \SigRandom$
\end{itemize}
@ -3449,7 +3467,7 @@ $(m', \sigma') \not\in \Oracle_{\sk}\mathsf{.}Q$.
\item Since $\SigRandomizePrivate(\SigRandomizer, \sk) :
\SigRandomizer \leftarrowR \SigRandom$ has an identical distribution to $\SigGenPrivate()$,
and since $\SigDerivePublic$ is a deterministic function, the combination of a re-randomized
public key and signature(s) under that key do not reveal the key from which it was
\publicKey and signature(s) under that key do not reveal the key from which it was
re-randomized.
\item Since $\SigRandomizePrivate_{\SigRandomizer}$ is injective and
easily invertible, knowledge of $\SigRandomizePrivate(\SigRandomizer, \sk)$
@ -3466,10 +3484,10 @@ A \defining{\keyHomomorphicSignatureScheme} $\Sig$ is a \signatureScheme that
additionally defines:
\begin{itemize}
\item an abelian group on private keys, with operation
\item an abelian group on \privateKeys, with operation
$\grpplus\!\! \typecolon \SigPrivate \times \SigPrivate \rightarrow \SigPrivate$ and
identity $\grpzero$;
\item an abelian group on public keys, with operation
\item an abelian group on \publicKeys, with operation
$\combplus\!\! \typecolon \SigPublic \times \SigPublic \rightarrow \SigPublic$ and
identity $\combzero$.
\end{itemize}
@ -3478,7 +3496,7 @@ additionally defines:
such that for any $\sk_{\oneto{2}} \typecolon \SigPrivate$,
$\SigDerivePublic(\sk_1 \grpplus \sk_2) = \SigDerivePublic(\sk_1)\, \combplus \SigDerivePublic(\sk_2)$.
In other words, $\SigDerivePublic$ is an injective homomorphism from the private key group to the public key group.
In other words, $\SigDerivePublic$ is an injective homomorphism from the \privateKey group to the \publicKey group.
\vspace{1ex}
\introlist
@ -3491,10 +3509,10 @@ For $\rmN \typecolon \PosInt$,
When $\rmN = 0$ these yield the appropriate group identity, i.e. $\sgrpsum{i=1}{0} \sk_i = \grpzero$
and $\scombsum{i=1}{0} \vk_i = \combzero$.
$\grpneg \sk$ means the private key such that $(\grpneg \sk) \grpplus \sk = \grpzero$,
$\grpneg \sk$ means the \privateKey such that $(\grpneg \sk) \grpplus \sk = \grpzero$,
and $\sk_1 \grpminus \sk_2$ means $\sk_1 \grpplus\, (\grpneg \sk_2)$.
$\combneg \vk$ means the public key such that $(\combneg \vk) \combplus \vk = \combzero$,
$\combneg \vk$ means the \publicKey such that $(\combneg \vk) \combplus \vk = \combzero$,
and $\vk_1 \combminus \vk_2$ means $\vk_1 \combplus\, (\combneg \vk_2)$.
\vspace{2ex}
@ -4111,7 +4129,7 @@ where
\item $\cmNew{\allNew} \typecolon \typeexp{\NoteCommitSproutOutput}{\NNew}$ is
the sequence of \noteCommitments for the output \notes;
\item \changed{$\EphemeralPublic \typecolon \KASproutPublic$ is
a key agreement public key, used to derive the key for encryption
a key agreement \publicKey, used to derive the key for encryption
of the \notesCiphertext (\crossref{sproutinband})};
\item \changed{$\RandomSeed \typecolon \RandomSeedType$ is
a seed that must be chosen independently at random for each
@ -4177,7 +4195,7 @@ where
\item $\rt \typecolon \MerkleHashSapling$ is an \anchor, as defined in
\crossref{blockchain}, for the output \treestate of a previous \block;
\item $\nf \typecolon \PRFOutputNfSapling$ is the \nullifier for the input \note;
\item $\AuthSignRandomizedPublic \typecolon \SpendAuthSigPublic$ is a randomized public key
\item $\AuthSignRandomizedPublic \typecolon \SpendAuthSigPublic$ is a randomized \publicKey
that should be used to verify $\spendAuthSig$;
\item $\ProofSpend \typecolon \SpendProof$ is a \zeroKnowledgeProof with \primaryInput
$(\cv, \rt, \nf, \AuthSignRandomizedPublic)$ for the \spendStatement defined in
@ -4197,7 +4215,7 @@ where
as defined in \crossref{sighash} using $\SIGHASHALL$.
The \spendAuthSignature{} \MUST be a valid $\SpendAuthSig$ signature over $\SigHash$
using $\AuthSignRandomizedPublic$ as the public key ---
using $\AuthSignRandomizedPublic$ as the \publicKey ---
i.e.\ $\SpendAuthSigVerify{\AuthSignRandomizedPublic}(\SigHash, \spendAuthSig) = 1$.
\end{consensusrules}
@ -4234,13 +4252,13 @@ where
\item $\cmU \typecolon \MerkleHashSapling$ is the result of applying $\ExtractJ$ (defined
in \crossref{concreteextractorjubjub}) to the \noteCommitment for the output \note;
\item $\EphemeralPublic \typecolon \KASaplingPublic$ is
a key agreement public key, used to derive the key for encryption
a key agreement \publicKey, used to derive the key for encryption
of the \noteCiphertext (\crossref{saplinginband});
\item $\TransmitCiphertext{} \typecolon \Ciphertext$ is
a ciphertext component for the encrypted output \note;
\item $\OutCiphertext{} \typecolon \Ciphertext$ is a ciphertext component that allows the holder of
a \fullViewingKey to recover the recipient \diversifiedTransmissionKey $\DiversifiedTransmitPublic$
and the ephemeral private key $\EphemeralPrivate$ (and therefore the entire \notePlaintext);
and the ephemeral \privateKey $\EphemeralPrivate$ (and therefore the entire \notePlaintext);
\item $\ProofOutput \typecolon \OutputProof$ is a \zeroKnowledgeProof with \primaryInput
$(\cv, \cmU, \EphemeralPublic)$ for the \outputStatement defined in \crossref{outputstatement}.
\end{itemize}
@ -4344,7 +4362,7 @@ the following steps:
\vspace{0.5ex}
\begin{itemize}
\item Check that $\DiversifiedTransmitPublic$ is of type $\KASaplingPublicPrimeOrder$, i.e.\ it
is a valid ctEdwards point on the \jubjubCurve (as defined in \crossref{jubjub})
is a valid \ctEdwardsCurve point on the \jubjubCurve (as defined in \crossref{jubjub})
not equal to $\ZeroJ$, and $\scalarmult{\ParamJ{r}}{\DiversifiedTransmitPublic} = \ZeroJ$.
\item Calculate $\DiversifiedTransmitBase = \DiversifyHash(\Diversifier)$
@ -4841,10 +4859,10 @@ other parties that are cooperating to create the \transaction. If all of the
} %pnote
\nnote{
The technique of checking signatures using a public key derived from a sum of
The technique of checking signatures using a \publicKey derived from a sum of
\xPedersenCommitments is also used in the \Mimblewimble protocol \cite{Jedusor2016}.
The private key $\BindingPrivate$ acts as a \definingquotedterm{synthetic blinding factor},
in the sense that it is synthesized from the other blinding factors (trapdoors)
The \privateKey $\BindingPrivate$ acts as a \definingquotedterm{synthetic blinding factor},
in the sense that it is synthesized from the other blinding factors (\trapdoors)
$\ValueCommitRandOld{\alln}$ and $\ValueCommitRandNew{\allm}$; this technique is
also used in \Bulletproofs \cite{Dalek-notes}.
} %nnote
@ -5241,7 +5259,7 @@ To transmit these secrets securely to a recipient
possession of the associated \incomingViewingKey $\InViewingKey$ is used to
reconstruct the original \note\changed{ and \memo}.
A single ephemeral public key is shared between encryptions of the $\NNew$
A single ephemeral \publicKey is shared between encryptions of the $\NNew$
\shieldedOutputs in a \joinSplitDescription. All of the resulting ciphertexts
are combined to form a \notesCiphertext.
@ -5296,7 +5314,7 @@ The resulting \notesCiphertext is $\changed{(\EphemeralPublic,
It is technically possible to replace $\TransmitCiphertext{i}$ for a given \note
with a random (and undecryptable) dummy ciphertext, relying instead on out-of-band
transmission of the \note to the recipient. In this case the ephemeral key \MUST
still be generated as a random public key (rather than a random bit sequence) to ensure
still be generated as a random \publicKey (rather than a random bit sequence) to ensure
indistinguishability from other \joinSplitDescriptions. This mode of operation raises
further security considerations, for example of how to validate a \SproutOrNothing{}
\note received out-of-band, which are not addressed in this document.
@ -5376,7 +5394,7 @@ possession of the associated \incomingViewingKey $\InViewingKey$ is used to
reconstruct the original \note and \memo.
Unlike in a \Sprout{} \joinSplitDescription, each \Sapling{} \shieldedOutput
is encrypted using a fresh ephemeral public key.
is encrypted by a fresh ephemeral \publicKey.
\vspace{0.5ex}
\introlist
@ -5422,7 +5440,7 @@ Let $\cvNew{}$ be the \valueCommitment for the new \note, and let $\cmNew{}$ be
Then to encrypt:
\begin{algorithm}
\vspace{-1ex}
\item choose a uniformly random ephemeral private key $\EphemeralPrivate \leftarrowR \KASaplingPrivate \setminus \setof{0}$
\item choose a uniformly random ephemeral \privateKey $\EphemeralPrivate \leftarrowR \KASaplingPrivate \setminus \setof{0}$
\item let $\EphemeralPublic = \KASaplingDerivePublic(\EphemeralPrivate, \DiversifiedTransmitBaseNew)$
\item let $\TransmitPlaintext{}$ be the raw encoding of $\NotePlaintext{}$
\item let $\DHSecret{} = \KASaplingAgree(\EphemeralPrivate, \DiversifiedTransmitPublicNew)$
@ -5447,7 +5465,7 @@ The resulting \noteCiphertext is $(\EphemeralPublic, \TransmitCiphertext{}, \Out
It is technically possible to replace $\TransmitCiphertext{}$ for a given \note
with a random (and undecryptable) dummy ciphertext, relying instead on out-of-band
transmission of the \note to the recipient. In this case the ephemeral key \MUST
still be generated as a random public key (rather than a random bit sequence) to ensure
still be generated as a random \publicKey (rather than a random bit sequence) to ensure
indistinguishability from other \outputDescriptions. This mode of operation raises
further security considerations, for example of how to validate a \Sapling{} \note
received out-of-band, which are not addressed in this document.
@ -6130,7 +6148,7 @@ the third address was derived from.
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
but works in any prime-order group.) ElGamal \publicKeys 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
@ -6347,8 +6365,8 @@ By injectivity of $\ItoLEBSP{\MerkleHashLengthSapling}$ and definitions of
$\PedersenHash$ and $\ExtractJ$, $\ItoLEBSPOf{\smash{\MerkleHashLengthSapling}}{1}$
can be in the range of $\PedersenHash$ only if there exist
$(D \typecolon \smash{\byteseq{8}}$, $M \typecolon \smash{\bitseq{\PosInt}})$ such that $\Selectu\Of{\PedersenHashToPoint(D, M)} = 1$.
The latter can only be the affine-ctEdwards $u$-coordinate of a point in $\strut\GroupJ$.
We show that there are no points in $\GroupJ$ with affine-ctEdwards $u$-coordinate $1$.
The latter can only be the \affineCtEdwards $u$-coordinate of a point in $\strut\GroupJ$.
We show that there are no points in $\GroupJ$ with \affineCtEdwards $u$-coordinate $1$.
Suppose for a contradiction that $(u, \varv) \in \GroupJ$ for $u = 1$ and some
$\varv \typecolon \GF{\ParamS{r}}$. By writing the curve equation as
$\varv^2 = (1 - \ParamJ{a} \smult u^2) / (1 - \ParamJ{d} \smult u^2)$, and noting that
@ -6664,12 +6682,12 @@ $\KASprout$ is a \keyAgreementScheme as specified in \crossref{abstractkeyagreem
It is instantiated as $\KASproutCurve$ key agreement, described in \cite{Bernstein2006},
as follows.
Let $\KASproutPublic$ and $\KASproutSharedSecret$ be the type of $\KASproutCurve$ public keys
Let $\KASproutPublic$ and $\KASproutSharedSecret$ be the type of $\KASproutCurve$ \publicKeys
(i.e.\ $\byteseq{32}$), and let $\KASproutPrivate$ be the type of $\KASproutCurve$
secret keys.
Let $\KASproutCurveMultiply(\bytes{n}, \bytes{q})$ be the result of point
multiplication of the $\KASproutCurve$ public key represented by the byte
multiplication of the $\KASproutCurve$ \publicKey represented by the byte
sequence $\bytes{q}$ by the $\KASproutCurve$ secret key represented by the
byte sequence $\bytes{n}$, as defined in \cite[section 2]{Bernstein2006}.
@ -6677,7 +6695,7 @@ Let $\KASproutBase := \KASproutCurveBase$ be the public byte sequence representi
the $\KASproutCurve$ base point.
Let $\KASproutCurveClamp(\bytes{x})$ take a 32-byte sequence $\bytes{x}$ as input
and return a byte sequence representing a $\KASproutCurve$ private key, with
and return a byte sequence representing a $\KASproutCurve$ \privateKey, with
bits ``clamped'' as described in \cite[section 3]{Bernstein2006}:
``clear bits $0, 1, 2$ of the first byte, clear bit $7$ of the last byte,
and set bit $6$ of the last byte.'' Here the bits of a byte are numbered
@ -6813,10 +6831,10 @@ represented by $\EdDSAReprR$ is permitted to be greater than $\ell$.
$\JoinSplitSigSpecific$ is defined as using $\JoinSplitSigHashName$ internally.
A valid $\JoinSplitSigSpecific$ public key is defined as a point of order $\ell$
A valid $\JoinSplitSigSpecific$ \publicKey is defined as a point of order $\ell$
on the $\JoinSplitSigSpecific$ curve, in the encoding specified by \cite{BDLSY2012}.
Again, it is \emph{not} required that the encoding of the $y$-coordinate of the
public key is less than $2^{255}-19$.
\publicKey is less than $2^{255}-19$.
}
\newsavebox{\sigbox}
@ -6839,7 +6857,7 @@ The encoding of a signature is:
\changed{
\vspace{-1ex}
where $\EdDSAReprR$ and $\EdDSAReprS$ are as defined in \cite{BDLSY2012}.
The encoding of a public key is as defined in \cite{BDLSY2012}.
The encoding of a \publicKey is as defined in \cite{BDLSY2012}.
}
@ -7000,7 +7018,7 @@ As required, $\RedDSADerivePublic$ is a group homomorphism:
\end{tabular}
\vspace{1ex}
A $\RedDSA$ public key $\vk$ can be encoded as a bit sequence $\reprG{}\Of{\vk}$\, of
A $\RedDSA$ \publicKey $\vk$ can be encoded as a bit sequence $\reprG{}\Of{\vk}$\, of
length $\ellG{}$ bits (or as a corresponding byte sequence $\vkBytes{}$ by then applying $\LEBStoOSP{\ellG{}}$).
\vspace{2ex}
@ -7053,7 +7071,7 @@ See \crossref{bindingsig} for details on the use of this \signatureScheme.
\securityrequirement{
$\BindingSig$ must be a SUF-CMA secure \keyHomomorphicSignatureScheme as defined in
\crossref{abstractsighom}. A signature must prove knowledge of the discrete logarithm of
the public key with respect to the base $\ValueCommitRandBase$.
the \publicKey with respect to the base $\ValueCommitRandBase$.
} %securityrequirement
} %sapling
@ -7512,12 +7530,12 @@ curve.
\zkSNARKCircuits, called ``Jubjub'' \cite{Carroll1876}.
The \representedGroup $\JubjubCurve$ of points on this curve is defined in this section.
A \completeTwistedEdwardsEllipticCurve, as defined in \cite[section 4.3.4]{BL2017}, is
an elliptic curve $E$ over a non-binary field $\GF{q}$, parameterized by distinct
A \defining{\completeTwistedEdwardsEllipticCurve}, as defined in \cite[section 4.3.4]{BL2017},
is an elliptic curve $E$ over a non-binary field $\GF{q}$, parameterized by distinct
$a, d \typecolon \GF{q} \setminus \setof{0}$ such that $a$ is square and $d$ is nonsquare,
with equation $E : a \smult u^2 + \varv^2 = 1 + d \smult u^2 \smult \varv^2$.
We use the abbreviation ``ctEdwards'' to refer to \completeTwistedEdwardsEllipticCurves and
coordinates.
We use the abbreviation ``\xCtEdwards'' to refer to \completeTwistedEdwardsEllipticCurves
and coordinates.
Let $\ParamJ{q} := \ParamS{r}$, as defined in \crossref{blspairing}.
@ -7531,7 +7549,7 @@ Let $\ParamJ{a} := -1$.
Let $\ParamJ{d} := -10240/10241 \pmod{\ParamJ{q}}$.
Let $\GroupJ$ be the group of points $(u, \varv)$ on a ctEdwards curve $\CurveJ$ over $\GF{\ParamJ{q}}$
Let $\GroupJ$ be the group of points $(u, \varv)$ on a \ctEdwardsCurve $\CurveJ$ over $\GF{\ParamJ{q}}$
with equation $\ParamJ{a} \smult u^2 + \varv^2 = 1 + \ParamJ{d} \smult u^2 \smult \varv^2$.
The zero point with coordinates $(0, 1)$ is denoted $\ZeroJ$.
$\GroupJ$ has order $\ParamJ{h} \smult \ParamJ{r}$.
@ -7557,8 +7575,8 @@ For the set of points of order $\ParamJ{r}$ (which excludes $\ZeroJ$), we write
Define $\SubgroupReprJ := \setof{\reprJ(P) \typecolon \ReprJ \suchthat P \in \SubgroupJ}$.
\begin{nnotes}
\item The encoding of a compressed ctEdwards point used here is
consistent with that used in EdDSA \cite{BJLSY2015} for public keys and
\item The \ctEdwardsCompressedEncoding used here is
consistent with that used in EdDSA \cite{BJLSY2015} for \publicKeys and
the $R$ element of a signature.
\item \cite[``Encoding and parsing curve points'']{BJLSY2015} gives algorithms
for decompressing points from the encoding of $\GroupJ$.
@ -7619,7 +7637,7 @@ since $\SubgroupJ$ is of odd order \cite{KvE2013}).
By writing the curve equation as
$\varv^2 = (1 - a \smult u^2) / (1 - d \smult u^2)$, and noting that the
potentially exceptional case $1 - d \smult u^2 = 0$ does not occur for a
ctEdwards curve, we see that for a given $u$ there can be at
\ctEdwardsCurve, we see that for a given $u$ there can be at
most two possible solutions for $\varv$, and that if there are two solutions
they can be written as $\varv$ and $-\varv$. In that case by the Lemma, at
most one of $(u, \varv)$ and $(u, -\varv)$ is in $\SubgroupJ$. Therefore,
@ -8036,7 +8054,7 @@ The raw encoding of a P2PKH address consists of:
\begin{bytefield}[bitwidth=0.1em]{176}
\sbitbox{80}{$8$-bit $\PtoPKHAddressLeadByte$}
\sbitbox{80}{$8$-bit $\PtoPKHAddressSecondByte$}
\sbitbox{160}{$160$-bit public key hash}
\sbitbox{160}{$160$-bit \publicKey hash}
\end{bytefield}
\end{equation*}
@ -8046,7 +8064,7 @@ The raw encoding of a P2PKH address consists of:
on the production network. (Addresses on the test network use
$[\PtoPKHAddressTestnetLeadByte, \PtoPKHAddressTestnetSecondByte]$
instead.)
\item $20$ bytes specifying a public key hash, which is a RIPEMD-160
\item $20$ bytes specifying a \publicKey hash, which is a RIPEMD-160
hash \cite{RIPEMD160} of a SHA-256 hash \cite{NIST2015}
of a compressed ECDSA key encoding.
\end{itemize}
@ -8104,7 +8122,7 @@ The raw encoding of a \SproutOrNothing \paymentAddress consists of:
}
\item $32$ bytes specifying $\AuthPublic$.
\item \changed{$32$ bytes} specifying $\TransmitPublic$, \changed{using the
normal encoding of a $\KASproutCurve$ public key \cite{Bernstein2006}}.
normal encoding of a $\KASproutCurve$ \publicKey \cite{Bernstein2006}}.
\end{itemize}
\pnote{
@ -8121,7 +8139,7 @@ cause the first two characters of the Base58Check encoding to be fixed as
A \Sapling \paymentAddress consists of $\Diversifier \typecolon \DiversifierType$
and $\DiversifiedTransmitPublic \typecolon \KASaplingPublicPrimeOrder$.
$\DiversifiedTransmitPublic$ is an encoding of a $\KASapling$ public key of type
$\DiversifiedTransmitPublic$ is an encoding of a $\KASapling$ \publicKey of type
$\KASaplingPublicPrimeOrder$ (see \crossref{concretesaplingkeyagreement}),
for use with the encryption scheme defined in \crossref{saplinginband}.
$\Diversifier$~is a sequence of $11$ bytes.
@ -8139,7 +8157,7 @@ The raw encoding of a \Sapling \paymentAddress consists of:
\begin{itemize}
\item $11$ bytes specifying $\Diversifier$.
\item $32$ bytes specifying the compressed ctEdwards encoding of
\item $32$ bytes specifying the \ctEdwardsCompressedEncoding of
$\DiversifiedTransmitPublic$ (see \crossref{jubjub}).
\end{itemize}
@ -8189,7 +8207,7 @@ The raw encoding of an \incomingViewingKey consists of, in order:
instead.)
\item $32$ bytes specifying $\AuthPublic$.
\item $32$ bytes specifying $\TransmitPrivate$, using the normal encoding
of a $\KASproutCurve$ private key \cite{Bernstein2006}.
of a $\KASproutCurve$ \privateKey \cite{Bernstein2006}.
\end{itemize}
$\TransmitPrivate$ \MUST be ``clamped'' using $\KASproutFormatPrivate$ as specified
@ -8262,9 +8280,9 @@ The raw encoding of a \fullViewingKey consists of:
\vspace{-1ex}
\begin{itemize}
\item $32$ bytes specifying the compressed ctEdwards encoding of $\AuthSignPublic$
\item $32$ bytes specifying the \ctEdwardsCompressedEncoding of $\AuthSignPublic$
(see \crossref{jubjub}).
\item $32$ bytes specifying the compressed ctEdwards encoding of $\AuthProvePublic$.
\item $32$ bytes specifying the \ctEdwardsCompressedEncoding of $\AuthProvePublic$.
\item $32$ bytes specifying the \outgoingViewingKey $\OutViewingKey$.
\end{itemize}
@ -8590,7 +8608,7 @@ $\versionField \geq 4$ and $\nShieldedSpend + \nShieldedOutput > 0$.
\coinbaseTransactions include \foundersReward outputs.
\item If $\versionField \geq 2$ and $\nJoinSplit > 0$, then:
\begin{itemize}
\item \joinSplitPubKey{} \MUST represent a valid $\JoinSplitSigSpecific$ public key
\item \joinSplitPubKey{} \MUST represent a valid $\JoinSplitSigSpecific$ \publicKey
encoding (\crossref{concretejssig}).
\item \joinSplitSig{} \MUST represent a valid signature under \joinSplitPubKey{} of
$\dataToBeSigned$, as defined in \crossref{sproutnonmalleability}.
@ -8722,7 +8740,7 @@ $64$ & $\commitmentsField$ & \type{char[32][$\NNew$]} & A sequence of \noteCommi
output \notes $\cmNew{\allNew}$. \\ \hline
\setchanged $32$ &\setchanged $\ephemeralKey$ &\setchanged \type{char[32]} &\mbox{}\setchanged
A $\KASproutCurve$ public key $\EphemeralPublic$. \\ \hline
A $\KASproutCurve$ \publicKey $\EphemeralPublic$. \\ \hline
\setchanged $32$ &\setchanged $\randomSeed$ &\setchanged \type{char[32]} &\mbox{}\setchanged
A $256$-bit seed that must be chosen independently at random for each \joinSplitDescription. \\ \hline
@ -8789,7 +8807,7 @@ at some \blockHeight in the past, $\LEBStoOSPOf{256}{\rt}$. \\ \hline
$32$ & $\nullifierField$ & \type{char[32]} & The \nullifier of the input \note,
$\LEBStoOSPOf{256}{\nf}$. \\ \hline
$32$ & $\rkField$ & \type{char[32]} & The randomized public key for $\spendAuthSig$,
$32$ & $\rkField$ & \type{char[32]} & The randomized \publicKey for $\spendAuthSig$,
$\LEBStoOSPOf{256}{\reprJ\Of{\AuthSignRandomizedPublic}\kern 0.05em}$. \\ \hline
$192$ & $\zkproof$ & \type{char[192]} & An encoding of the \zeroKnowledgeProof
@ -8832,7 +8850,7 @@ $\LEBStoOSPOf{256}{\reprJ\Of{\cv}\kern 0.05em}$. \\ \hline
$32$ & $\cmuField$ & \type{char[32]} & The $u$-coordinate of the \noteCommitment for the output \note,
$\LEBStoOSPOf{256}{\cmU}$ where $\cmU = \ExtractJ(\cm)$. \\ \hline
$32$ & $\ephemeralKey$ & \type{char[32]} & An encoding of an ephemeral $\JubjubCurve$ public key,
$32$ & $\ephemeralKey$ & \type{char[32]} & An encoding of an ephemeral $\JubjubCurve$ \publicKey,
$\LEBStoOSPOf{256}{\reprJ\Of{\EphemeralPublic}}$. \\ \hline
$580$ & $\encCiphertext$ & \type{char[580]} & A ciphertext component for the
@ -9594,7 +9612,7 @@ supposed to choose a new $\NoteAddressRand$ value at random.
The \nullifier of the \note is derived from its \spendingKey
($\AuthPrivate$) and $\NoteAddressRand$. The \noteCommitment
is derived from the recipient address component $\AuthPublic$,
the value $\Value$, and the commitment trapdoor $\NoteCommitRand$,
the value $\Value$, and the \commitmentTrapdoor $\NoteCommitRand$,
as well as $\NoteAddressRand$. However nothing prevents creating
multiple \notes with different $\Value$ and $\NoteCommitRand$
(hence different \noteCommitments) but the same $\NoteAddressRand$.
@ -9673,7 +9691,7 @@ $\NoteAddressRand$ for each output \note is enforced by
\sproutspecific{
Now even if the creator of a \joinSplitDescription does not choose
$\NoteAddressPreRand$ randomly, uniqueness of \nullifiers and
collision resistance of both $\hSigCRH$ and $\PRFrho{}$ will ensure
\collisionResistance of both $\hSigCRH$ and $\PRFrho{}$ will ensure
that the derived $\NoteAddressRand$ values are unique, at least for
any two \joinSplitDescriptions that get into a \validBlockchain.
This is sufficient to prevent the Faerie Gold attack.
@ -9720,7 +9738,7 @@ $\NoteAddressRand = \cm + \scalarmult{\NotePosition}{\NotePositionBase}$,
where $\NotePositionBase$ is a generator independent of the generators
used in $\NoteCommitSaplingAlg$. Therefore, $\NoteAddressRand$ commits uniquely
to the \note and its position, and this commitment is \collisionResistant
by the same argument used to prove collision resistance of \xPedersenHashes.
by the same argument used to prove \collisionResistance of \xPedersenHashes.
Note that it is possible for two distinct \Sapling \positionedNotes (having
different $\NoteAddressRand$ values and \nullifiers, but different
\notePositions) to have the same \noteCommitment, but this causes no security
@ -9834,10 +9852,10 @@ twice.
\sproutspecific{
For resistance to Faerie Gold attacks as described in
\crossref{faeriegold}, \Zcash depends on collision resistance of
\crossref{faeriegold}, \Zcash depends on \collisionResistance of
$\hSigCRH$ and $\PRFrho{}$ (instantiated using $\BlakeTwob{256}$ and
$\SHACompress$ respectively). Collision resistance of a truncated hash
does not follow from collision resistance of the original hash, even if the
$\SHACompress$ respectively). \xCollisionResistance of a truncated hash
does not follow from \collisionResistance of the original hash, even if the
truncation is only by one bit. This motivated avoiding truncation along any
path from the inputs to the computation of $\hSig$ to the uses of
$\NoteAddressRand$.
@ -9888,7 +9906,7 @@ The motivations for this change were as follows:
similar design process following the ``Safe curves'' criteria
\cite{BL-SafeCurves} \cite{Hopwood2018}.
This retains $\KASproutCurve$'s advantages while keeping \paymentAddress sizes
short, because the same public key material supports both encryption and
short, because the same \publicKey material supports both encryption and
spend authentication.}
\item ECIES permits many options, which were not specified. There are at least
--counting conservatively-- 576 possible combinations of options and
@ -9899,19 +9917,19 @@ The motivations for this change were as follows:
all curve parameters and key distributions. For example, if a group of
non-prime order is used, the distribution of ciphertexts could be
distinguishable depending on the order of the points representing the
ephemeral and recipient public keys. Public key validity is also a concern.
ephemeral and recipient \publicKeys. Public key validity is also a concern.
$\KASproutCurve$ \sapling{(and $\JubjubCurve$)} key agreement is defined in a way that
avoids these concerns due to the curve structure and the ``clamping'' of
private keys\sapling{ (or explicit cofactor multiplication and point
\privateKeys\sapling{ (or explicit cofactor multiplication and point
validation for \Sapling)}.
\item Unlike the DHAES/DHIES proposal on which it is based \cite{ABR1999}, ECIES
does not require a representation of the sender's ephemeral public key
does not require a representation of the sender's ephemeral \publicKey
to be included in the input to the KDF, which may impair the security
properties of the scheme. (The Std 1363a-2004 version of ECIES \cite{IEEE2004}
has a ``DHAES mode'' that allows this, but the representation of the key
input is underspecified, leading to incompatible implementations.)
The scheme we use\notsprout{ for \Sprout} has both the ephemeral and
recipient public key encodings --which are unambiguous for $\KASproutCurve$--
recipient \publicKey encodings --which are unambiguous for $\KASproutCurve$--
and also $\hSig$ and a nonce as described below, as input to the KDF.
\sapling{For \Sapling, it is only possible to include the ephemeral public
key encoding, but this is sufficient to retain the original security properties
@ -9941,9 +9959,9 @@ The motivations for this change were as follows:
The security proofs of \cite{ABR1999} can be adapted straightforwardly to the
resulting scheme. Although DHAES as defined in that paper does not pass the
recipient public key or a public seed to the \hashFunction $H$, this does not
recipient \publicKey or a public seed to the \hashFunction $H$, this does not
impair the proof because we can consider $H$ to be the specialization of our
KDF to a given recipient key and seed. (Passing the recipient public key to
KDF to a given recipient key and seed. (Passing the recipient \publicKey to
the KDF could in principle compromise \keyPrivacy, but not confidentiality of
encryption.) \sproutspecific{It is necessary to adapt the
``HDH independence'' assumptions and the proof slightly to take into account
@ -10003,7 +10021,7 @@ in \Zerocash and \SproutOrZcash, which \emph{are} \collisionResistant assuming
that $\SHACompress$ is.
The proof can be straightforwardly repaired. The intuition is that we can rely
on collision resistance of $\PRFaddr{}$ (on both its arguments) to argue that
on \collisionResistance of $\PRFaddr{}$ (on both its arguments) to argue that
distinctness of $\AuthPrivateOldX{1}$ and $\AuthPrivateOldX{2}$, together with
constraint 1(b) of the \joinSplitStatement (see \crossref{sproutspendauthority}),
implies distinctness of $\AuthPublicOldX{1}$ and $\AuthPublicOldX{2}$, therefore
@ -10315,7 +10333,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}.
\item Correct uses of $\LEOStoIP{\ell}$ in $\RedDSAVerify{}$ and $\RedDSABatchVerify{}$
to ensure that $\ell$ is a multiple of $8$ as required.
\item Minor changes to avoid clashing notation for
Edwards curves $\Edwards{a,d}$, Montgomery curves $\Montgomery{A,B}$, and
Edwards curves $\Edwards{a,d}$, \MontgomeryCurves $\Montgomery{A,B}$, and
extractors $\Extractor{\Adversary}$.
\item Correct a use of $\GroupJ$ that should have been $\MontCurve$ in the proof of
\theoremref{thmdistinctx}, and make a minor tweak to the theorem statement
@ -10519,8 +10537,8 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}.
\item Correct the conformance rule for \fOverwintered{} (it must not be set before \Overwinter has
activated, not before \Sapling has activated).
\item Correct the argument that $\vSum$ is in range in \crossref{saplingbalance}.
\item Correct an error in the algorithm for $\RedDSAVerify{}$: the public key $\vk$ is given directly
to this algorithm and should not be computed from the unknown private key $\sk$.
\item Correct an error in the algorithm for $\RedDSAVerify{}$: the \publicKey $\vk$ is given directly
to this algorithm and should not be computed from the unknown \privateKey $\sk$.
\item Correct or improve the types of $\GroupJHash{}$, $\FindGroupJHash$, $\ExtractJ$, $\PRFexpand{}$,
$\PRFock{}$, and $\CRHivk$.
\item Instantiate $\PRFock{}$ using $\BlakeTwob{256}$.
@ -10571,7 +10589,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}.
\item Correct a type error in \crossref{concretegrouphashjubjub}.
\item Correct a type error in $\RedDSASign{}$ in \crossref{concreteredjubjub}.
\item Ensure $\AuthSignBase$ is defined in \crossref{concretespendauthsig}.
\item Make the public key prefix part of the input to the \hashFunction in $\RedDSA$,
\item Make the \publicKey prefix part of the input to the \hashFunction in $\RedDSA$,
not part of the message.
\item Correct the statement about $\FindGroupJHash$ never returning $\bot$.
\item Correct an error in the computation of generators for \xPedersenHashes.
@ -10643,7 +10661,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}.
of verifying keys independent of key pair generation.
\sapling{
\item Correct the explanation in \crossref{overview} to apply to \Sapling.
\item Add the definition of a private key to public key homomorphism for \signatureSchemes.
\item Add the definition of a \privateKey to \publicKey homomorphism for \signatureSchemes.
\item Remove the output index as an input to $\KDFSapling$.
\item Allow dummy \Sapling input \notes.
\item Specify $\RedDSA$ and $\RedJubjub$.
@ -10837,7 +10855,7 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}.
\begin{itemize}
\item Specify more precisely the requirements on $\JoinSplitSigSpecific$
public keys and signatures.
\publicKeys and signatures.
\sapling{
\item \Sapling work in progress.
}
@ -11222,14 +11240,14 @@ in \crossref{notation}.
\lsubsection{Elliptic curve background}{ecbackground}
The \Sapling circuits make use of a \completeTwistedEdwardsEllipticCurve (``ctEdwards curve'')
The \Sapling circuits make use of a \completeTwistedEdwardsEllipticCurve (``\ctEdwardsCurve'')
$\JubjubCurve$, defined in \crossref{jubjub}, and also a \MontgomeryEllipticCurve $\MontCurve$
that is birationally equivalent to $\JubjubCurve$. Following the notation in \cite{BL2017} we use
$(u, \varv)$ for affine coordinates on the ctEdwards curve, and $(x, y)$ for
affine coordinates on the Montgomery curve.
$(u, \varv)$ for affine coordinates on the \ctEdwardsCurve, and $(x, y)$ for
affine coordinates on the \MontgomeryCurve.
A point $P$ is normally represented by two $\GF{\ParamS{r}}$ variables, which
we name as $(P^u, P^{\vv})$ for an affine-ctEdwards point, for instance.
we name as $(P^u, P^{\vv})$ for an \affineCtEdwards point, for instance.
The implementations of scalar multiplication require the scalar to be represented
as a bit sequence. We therefore allow the notation $\scalarmult{k\Repr}{P}$ meaning
@ -11237,7 +11255,7 @@ $\scalarmult{\LEBStoIPOf{\length(k\Repr)}{k\Repr}}{P}$. There will be no ambigui
because variables representing bit sequences are named with a $\Repr$ suffix.
\introlist
The Montgomery curve $\MontCurve$ has parameters $\ParamM{A} = 40962$ and $\ParamM{B} = 1$.
The \MontgomeryCurve $\MontCurve$ has parameters $\ParamM{A} = 40962$ and $\ParamM{B} = 1$.
We use an affine representation of this curve with the formula:
\begin{formulae}
@ -11251,7 +11269,7 @@ implemented at the same cost as a multiplication, i.e.\ one constraint.
Therefore it is beneficial to use affine coordinates for both curves.
\introlist
We define the following types representing affine-ctEdwards and affine-Montgomery
We define the following types representing \affineCtEdwards and \affineMontgomery
coordinates respectively:
\begin{tabular}{@{\hskip 2em}r@{\;}l@{\;}l}
@ -11273,8 +11291,8 @@ See \crossref{jubjub} for how this type is represented as a byte sequence in
external encodings.
\vspace{2ex}
We use affine Montgomery arithmetic in parts of the circuit because it is
more efficient, in terms of the number of constraints, than affine-ctEdwards
We use \affineMontgomery arithmetic in parts of the circuit because it is
more efficient, in terms of the number of constraints, than \affineCtEdwards
arithmetic.
An important consideration when using Montgomery arithmetic is that the
@ -11283,7 +11301,7 @@ the wrong answer. We must ensure that these cases do not arise.
\introlist
We will need the theorem below about $y$-coordinates of points on
Montgomery curves.
\MontgomeryCurves.
\vspace{1ex}
\fact{$\ParamM{A}^2 - 4$ is a nonsquare in $\GF{\ParamS{r}}$.}
@ -11298,7 +11316,7 @@ Then $y \neq 0$.
\end{theorem}
\begin{proof}
Substituting $y = 0$ into the Montgomery curve equation gives
Substituting $y = 0$ into the \MontgomeryCurve equation gives
$0 = x^3 + A \mult x^2 + x = x \mult (x^2 + A \mult x + 1)$.
So either $x = 0$ or $x^2 + A \mult x + 1 = 0$.
Since $P \neq (0, 0)$, the case $x = 0$ is excluded.
@ -11553,7 +11571,7 @@ Correctness of the full constraint system follows by taking $m = 0$ in the above
\vspace{1ex}
The algorithm in \crossref{ccteddecompressvalidate} uses range checks with
$c = \ParamS{r}-1$ to validate compressed ctEdwards points. In that case $n = 255$ and
$c = \ParamS{r}-1$ to validate \ctEdwardsCompressedEncodings. In that case $n = 255$ and
$k = 132$, so the cost of each such range check is $387$ constraints.
\introsection
@ -11591,10 +11609,10 @@ These optimizations are not used in \Sapling.}
\introsection
\lsubsubsection{Elliptic curve operations}{cctelliptic}
\lsubsubsubsection{Checking that affine-ctEdwards coordinates are on the curve}{cctedvalidate}
\lsubsubsubsection{Checking that \AffineCtEdwards{} coordinates are on the curve}{cctedvalidate}
\vspace{-1ex}
To check that $(u, \varv)$ is a point on the ctEdwards curve, the \Sapling circuit uses
To check that $(u, \varv)$ is a point on the \ctEdwardsCurve, the \Sapling circuit uses
$4$ constraints:
\begin{formulae}
@ -11624,7 +11642,7 @@ as follows:
\item \tab Let $u \typecolon \GF{\ParamS{r}}$.
\vspace{1ex}
\item \tab // \crossref{cctedvalidate}.
\item \tab Check that $(u, \varv)$ is a point on the ctEdwards curve.
\item \tab Check that $(u, \varv)$ is a point on the \ctEdwardsCurve.
\vspace{1ex}
\item \tab // \crossref{cctmodpack}.
\item \tab Unpack $u$ to $\ssum{i=0}{254} u_i \mult 2^i$, equating $\tilde{u}$ with $u_0$.
@ -11706,7 +11724,7 @@ obtain $\varv = \pm 1$, and by substituting $\varv = 1$ and using $a \neq d$ we
Let $(x, y)$ be an affine point on a \MontgomeryCurve $\Montgomery{A,B}$ over $\GF{r}$
with parameters $A$ and $B$ such that $A^2 - 4$ is a nonsquare in $\GF{r}$,
that is birationally equivalent to a ctEdwards curve.
that is birationally equivalent to a \ctEdwardsCurve.
Then $x + 1 \neq 0$, and the only point $(x, y)$ with $y = 0$ is
$(0, 0)$ of order 2.
\end{theorem}
@ -11714,25 +11732,25 @@ $(0, 0)$ of order 2.
\begin{proof}
That the only point with $y = 0$ is $(0, 0)$ is proven by \theoremref{thmmontynotzero}.
If $x + 1 = 0$, then subtituting $x = -1$ into the Montgomery curve equation gives
If $x + 1 = 0$, then subtituting $x = -1$ into the \MontgomeryCurve equation gives
$B \mult y^2 = x^3 + A \mult x^2 + x = A - 2$.
So in that case $y^2 = (A - 2)/B$. The right-hand-side is equal
to the parameter $d$ of a particular ctEdwards curve birationally
equivalent to the Montgomery curve (see \cite[section 4.3.5]{BL2017}).
For all ctEdwards curves, $d$ is nonsquare, so this equation
to the parameter $d$ of a particular \ctEdwardsCurve birationally
equivalent to the \MontgomeryCurve (see \cite[section 4.3.5]{BL2017}).
For all \ctEdwardsCurves, $d$ is nonsquare, so this equation
has no solutions for $y$, hence $x + 1 \neq 0$.
\end{proof}
(When the theorem is applied with $\Montgomery{A,B} = \MontCurve$ defined in \crossref{ecbackground},
the ctEdwards curve referred to in the proof is an isomorphic
the \ctEdwardsCurve referred to in the proof is an isomorphic
rescaling of the \jubjubCurve.)
\introsection
\lsubsubsubsection{Affine-Montgomery arithmetic}{cctmontarithmetic}
\lsubsubsubsection{\AffineMontgomery arithmetic}{cctmontarithmetic}
\vspace{-1ex}
The incomplete affine-Montgomery addition formulae given in
The incomplete \affineMontgomery addition formulae given in
\cite[section 4.3.2]{BL2017} are:
\begin{formulae}
@ -11767,7 +11785,7 @@ $k_2 \neq \pm k_1$. Then the non-unified addition constraints
\item $\constraint{x_1 - x_3}{\lambda}{y_3 + y_1}$
\end{formulae}
\vspace{-0.5ex}
implement the affine-Montgomery addition $P_1 + P_2 = (x_3, y_3)$ for all such $P_\barerange{1}{2}$.
implement the \affineMontgomery addition $P_1 + P_2 = (x_3, y_3)$ for all such $P_\barerange{1}{2}$.
\end{theorem}
\begin{proof}
@ -11792,7 +11810,7 @@ $k_2 \neq \pm k_1$.
\vspace{2ex}
\introlist
Affine-Montgomery doubling can be implemented as:
\xAffineMontgomery doubling can be implemented as:
\begin{formulae}
\item $\constraint{x}{x}{xx}$
@ -11807,9 +11825,9 @@ is not the point $(0, 0)$ (the only point of order $2$), as proven in
\introlist
\lsubsubsubsection{Affine-ctEdwards arithmetic}{cctedarithmetic}
\lsubsubsubsection{\AffineCtEdwards{} arithmetic}{cctedarithmetic}
Formulae for affine-ctEdwards addition are given in \cite[section 6]{BBJLP2008}.
Formulae for \affineCtEdwards addition are given in \cite[section 6]{BBJLP2008}.
With a change of variable names to match our convention, the formulae for
$(u_1, \varv_1) + (u_2, \varv_2) = (u_3, \varv_3)$ are:
@ -11845,7 +11863,7 @@ The correctness of this implementation can be seen by expanding $T - A + \ParamJ
\vspace{2ex}
\introlist
The above addition formulae are ``unified'', that is, they can also be
used for doubling. Affine-ctEdwards doubling $\scalarmult{2}{(u, \varv)} = (u_3, \varv_3)$
used for doubling. \xAffineCtEdwards doubling $\scalarmult{2}{(u, \varv)} = (u_3, \varv_3)$
can also be implemented slightly more efficiently as:
\begin{formulae}
@ -11861,7 +11879,7 @@ $(u, \varv) = (u_1, \varv_1) = (u_2, \varv_2)$ and observing that $u \mult \varv
\introsection
\lsubsubsubsection{Affine-ctEdwards nonsmall-order check}{cctednonsmallorder}
\lsubsubsubsection{\AffineCtEdwards{} nonsmall-order check}{cctednonsmallorder}
In order to avoid small-subgroup attacks, we check that certain points used in the
circuit are not of small order. In practice the \Sapling circuit uses this
@ -11873,7 +11891,7 @@ To check for a point $P$ of order $8$ or less, the \Sapling circuit doubles
three times (as in \crossref{cctedarithmetic}) and checks that the resulting
$u$-coordinate is not $0$ (as in \crossref{cctnonzero}).
On a ctEdwards curve, only the zero point $\ZeroJ$, and the unique point
On a \ctEdwardsCurve, only the zero point $\ZeroJ$, and the unique point
of order $2$ at $(0, -1)$ have zero $u$-coordinate. The point of order $2$ cannot
occur as the result of three doublings. So this $u$-coordinate check rejects
only $\ZeroJ$.
@ -11896,7 +11914,7 @@ The total cost, including the curve check, is $4 + 3 \mult 5 + 1 = 20$ constrain
\introsection
\lsubsubsubsection{Fixed-base affine-ctEdwards scalar multiplication}{cctfixedscalarmult}
\lsubsubsubsection{Fixed-base \AffineCtEdwards{} scalar multiplication}{cctfixedscalarmult}
If the base point $B$ is fixed for a given scalar multiplication $\scalarmult{k}{B}$,
we can fully precompute window tables for each window position.
@ -11950,10 +11968,10 @@ None of these costs include the cost of boolean-constraining the scalar.
\begin{nnotes}
\vspace{-0.5ex}
\item It would be more efficient to use arithmetic on the Montgomery curve, as in
\item It would be more efficient to use arithmetic on the \MontgomeryCurve, as in
\crossref{cctpedersenhash}. However since there are only three instances of
fixed-base scalar multiplication in the \spendCircuit and two in the
\outputCircuit\footnote{A Pedersen commitment uses fixed-base scalar multiplication as a subcomponent.},
\outputCircuit\footnote{A \xPedersenCommitment uses fixed-base scalar multiplication as a subcomponent.},
the additional complexity was not considered justified for \Sapling.
\item For the multiplications with $64$-bit and $32$-bit scalars, the scalar is
padded to a multiple of $3$ bits with zeros. This causes the computation
@ -11965,7 +11983,7 @@ None of these costs include the cost of boolean-constraining the scalar.
\introsection
\lsubsubsubsection{Variable-base affine-ctEdwards scalar multiplication}{cctvarscalarmult}
\lsubsubsubsection{Variable-base \AffineCtEdwards{} scalar multiplication}{cctvarscalarmult}
\vspace{-1.5ex}
When the base point $B$ is not fixed, the method in the preceding section
@ -11996,7 +12014,7 @@ for a total of $3252$ constraints.
\nnote{
It would be more efficient to use $2$-bit fixed windows, and/or to use arithmetic
on the Montgomery curve in a similar way to \crossref{cctpedersenhash}. However
on the \MontgomeryCurve in a similar way to \crossref{cctpedersenhash}. However
since there are only two instances of variable-base scalar multiplication in the
\spendCircuit and one in the \outputCircuit, the additional complexity was not
considered justified for \Sapling.
@ -12029,17 +12047,17 @@ if the set $\range{1}{8}$ had been used, because a point can be conditionally
negated using only a single constraint.
Next, we optimize the cost of point addition by allowing as many additions
as possible to be performed on the Montgomery curve. An incomplete
as possible to be performed on the \MontgomeryCurve. An incomplete
Montgomery addition costs $3$ constraints, in comparison with a
ctEdwards addition which costs $6$ constraints.
However, we cannot do all additions on the Montgomery curve because the
However, we cannot do all additions on the \MontgomeryCurve because the
Montgomery addition is incomplete. In order to be able to prove that
exceptional cases do not occur, we need to ensure that the \distinctXCriterion
from \crossref{cctmontarithmetic} is met. This requires splitting the
input into segments (each using an independent generator), calculating
an intermediate result for each segment, and then converting to the
ctEdwards curve and summing the intermediate results using
\ctEdwardsCurve and summing the intermediate results using
ctEdwards addition.
\introlist
@ -12186,7 +12204,7 @@ The cost is then:
\begin{itemize}
\item $2 \smult c$ constraints for the lookups;
\item $3 \smult (c-n)$ constraints for incomplete additions on the Montgomery curve;
\item $3 \smult (c-n)$ constraints for incomplete additions on the \MontgomeryCurve;
\item $2 \smult n$ constraints for Montgomery-to-ctEdwards conversions;
\item $6 \smult (n-1)$ constraints for ctEdwards additions;
\end{itemize}
@ -12729,7 +12747,7 @@ Check & Implements & \heading{Cost} & Reference \\
& $\EphemeralPrivate \typecolon \binaryrange{\ScalarLength}$
& 252 & \shortcrossref{cctboolean} \\ \hline
$\EphemeralPublic = \scalarmult{\EphemeralPrivateRepr}{\DiversifiedTransmitBase}$
& \snarkref{Ephemeral public key integrity}{outputepkintegrity}
& \snarkref{Ephemeral \publicKey integrity}{outputepkintegrity}
& 3252 & \shortcrossref{cctvarscalarmult} \\ \hline
inputize $\EphemeralPublic$
&
@ -12772,7 +12790,7 @@ be as defined in that section.
Implementations \MAY alternatively use the optimized procedure described in this section to perform
faster verification of a batch of signatures, i.e.\ to determine whether all signatures in a batch are valid.
Its input is a sequence of $N$ \defining{\sigBatchEntries}, each of which is a
(public key, message, signature) triple.
(\publicKey, message, signature) triple.
\vspace{2ex}
Let $\LEOStoBSP{}$, $\LEOStoIP{}$, and $\LEBStoOSP{}$ be as defined in \crossref{endian}.