* Specify that diversifier indices for Orchard should be chosen uniquely, not randomly.

* Vanity diversifiers are not an issue for Orchard given that it does not have its own
  payment address format, and given the use of "jumbling" (ZIP 316) in unified addresses.
  Remove the corresponding note from \crossref{orchardkeycomponents}.

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
Daira Hopwood 2021-04-29 13:31:34 +01:00
parent 2cf14204ae
commit 58add67726
2 changed files with 19 additions and 9 deletions

View File

@ -1043,6 +1043,8 @@ electronic commerce and payment, financial privacy, proof of work, zero knowledg
\newcommand{\diversifiers}{\terms{diversifier}}
\newcommand{\diversifierKey}{\term{diversifier key}}
\newcommand{\diversifierIndex}{\term{diversifier index}}
\newcommand{\diversifierIndices}{\termandindex{diversifier indices}{diversifier index}}
\newcommand{\xDiversifierIndices}{\termandindex{Diversifier indices}{diversifier index}}
\newcommand{\incomingViewingKey}{\term{incoming viewing key}}
\newcommand{\incomingViewingKeys}{\terms{incoming viewing key}}
\newcommand{\outgoingViewingKey}{\term{outgoing viewing key}}
@ -4903,8 +4905,7 @@ authority. A group of such addresses shares the same \fullViewingKey,
\introlist
To create a new \diversifiedPaymentAddress given an \incomingViewingKey
$\InViewingKey$, pick a \defining{\diversifierIndex} $\DiversifierIndex$ uniformly at
random from $\DiversifierType$.
$\InViewingKey$, pick a \defining{\diversifierIndex} $\DiversifierIndex$ uniquely from $\DiversifierType$.
Then calculate the \defining{\diversifiedTransmissionKey} $\DiversifiedTransmitPublic$:
\begin{formulae}
@ -4923,13 +4924,8 @@ The \diversifiedPaymentAddress with \diversifierIndex $0$ is called the \definin
\vspace{1ex}
\begin{pnotes}
\item The protocol does not prevent using the \diversifier $\Diversifier$ to produce
\quotedtermnoindex{vanity} addresses that start with or contain meaningful
strings when encoded in \Bechm (see \crossref{unifiedpaymentaddrencoding}).
Users and writers of software that generates addresses should be aware that
this provides weaker privacy properties than a randomly chosen \diversifier,
since a vanity address can obviously be distinguished, and might leak more
information than intended as to who created it.
\item \xDiversifierIndices \SHOULDNOT be chosen at random. \cite{ZIP-32} specifies their
usage in the context of hierarchical deterministic wallets.
\item Address generators \MAY encode information in the \diversifierIndex
that can be recovered by the recipient of a payment, given the \diversifierKey.
\item $\CommitIvkRandom$ is used both as a randomizer for $\CommitIvk{}$, and as a
@ -14258,6 +14254,11 @@ Peter Newell's illustration of the Jubjub bird, from \cite{Carroll1902}.
\item Include $\NoteUniqueRand$ as an input to the derivation of
$\NoteNullifierRand$, $\EphemeralPrivate$, and $\NoteCommitRand$ in \Orchard.
This was originally intended and as described in \cite[Section 3.5 Nullifiers]{Zcash-Orchard}.
\item Specify that \diversifierIndices for \Orchard \paymentAddresses should be chosen
uniquely, not randomly.
\item Vanity \diversifiers are not an issue for \Orchard given that it does not have its own
\paymentAddress format, and given the use of ``jumbling'' (\cite{ZIP-316}) in
\unifiedPaymentAddresses. Remove the corresponding note from \crossref{orchardkeycomponents}.
\item Clarify the definition of $\pad$ in \crossref{concretesinsemillahash} by
disambiguating $\Mpieces$ from $\Mpadded$.
} %nufive

View File

@ -1417,6 +1417,15 @@ Last revised February~5, 2018.}
urldate={2020-02-13}
}
@misc{ZIP-316,
presort={ZIP-0316},
author={Daira Hopwood and Nathan Wilcox and Taylor Hornby and Jack Grigg and Sean Bowe and Kris Nuttycombe and Ying Tong Lai},
title={Unified Addresses},
howpublished={Zcash Improvement Proposal 316. Created April~7, 2021.},
url={https://zips.z.cash/zip-0316},
urldate={2021-04-29}
}
@misc{DigiByte-PoW,
presort={DigiByte-PoW},
author={DigiByte Core Developers},