mirror of https://github.com/zcash/zips.git
200 lines
10 KiB
ReStructuredText
200 lines
10 KiB
ReStructuredText
|
::
|
||
|
|
||
|
ZIP: 212
|
||
|
Title: Allow Recipient to Derive Sapling Ephemeral Secret from Note Plaintext
|
||
|
Owners: Sean Bowe <sean@electriccoin.co>
|
||
|
Status: Proposed
|
||
|
Category: Consensus
|
||
|
Created: 2019-03-31
|
||
|
License: MIT
|
||
|
|
||
|
|
||
|
Terminology
|
||
|
===========
|
||
|
|
||
|
The key words "MUST" and "MUST NOT" in this document are to be interpreted as described in RFC 2119.
|
||
|
|
||
|
The function ``ToScalar`` is defined as in Section 4.4.2 of the Zcash Protocol Specification. [#protocol]_
|
||
|
|
||
|
Abstract
|
||
|
========
|
||
|
|
||
|
This ZIP proposes a new note plaintext format for Sapling Outputs in
|
||
|
transactions. The new format allows recipients to check the well-formedness of
|
||
|
the emphemeral Diffie-Hellman key in the Output to avoid an assumption on
|
||
|
zk-SNARK soundness for preventing diversified address linkability.
|
||
|
|
||
|
Motivation
|
||
|
==========
|
||
|
|
||
|
The Sapling payment protocol contains a feature called "diversified addresses"
|
||
|
which allows a single incoming viewing key to receive payments on an enormous
|
||
|
number of distinct and unlinkable payment addresses. This feature allows users
|
||
|
to maintain many payment addresses without paying additional overhead during
|
||
|
blockchain scanning.
|
||
|
|
||
|
The feature works by allowing payment addresses to become a tuple (``pk_d``,
|
||
|
``d``) of a public key ``pk_d`` and 88-bit diversifier ``d`` such that ``pk_d =
|
||
|
[ivk] GH(d)`` for some incoming viewing key ``ivk``. The hash function ``GH(d)``
|
||
|
maps from a diversifier to prime order elements of the Jubjub elliptic curve. It
|
||
|
is possible for a user to choose many ``d`` to create several distinct and
|
||
|
unlinkable payment addresses of this form.
|
||
|
|
||
|
In order to make a payment to a Sapling address, an ephemeral secret ``esk`` is
|
||
|
sampled by the sender and an ephemeral public key ``epk = [esk] GH(d)`` is
|
||
|
included in the Output description. Then, a shared Diffie-Hellman secret is
|
||
|
computed by the sender as ``[esk] [8] pk_d``. The recipient can recover this
|
||
|
shared secret without knowledge of the particular ``d`` by computing ``[ivk] [8]
|
||
|
epk``. This shared secret is then used as part of Note decryption.
|
||
|
|
||
|
Naively, the recipient cannot know which ``(pk_d, d)`` was used to compute the
|
||
|
shared secret, but the sender is asked to include the ``d`` within the note
|
||
|
plaintext to reconstruct the Note. However, if the recipient has more than one
|
||
|
known addresses, an attacker could use a different payment address to perform
|
||
|
secret exchange and, by observing the behavior of the recipient, link the two
|
||
|
diversified addresses together. (This attacker strategy was discovered by Brian
|
||
|
Warner earlier in the design of the Sapling protocol.)
|
||
|
|
||
|
In order to prevent this attack, the protocol currently forces the sender to
|
||
|
prove knowledge of the discrete logarithm of ``epk`` with respect to the ``g_d =
|
||
|
GH(d)`` included within the Note commitment. This ``g_d`` is determined by ``d``
|
||
|
and recomputed during Note decryption, and so the recipient will either be
|
||
|
unable to decrypt the note or the sender will be unable to perform the attack.
|
||
|
|
||
|
However, this check occurs as part of the zero-knowledge proof statement and so
|
||
|
relies on the soundness of the underlying zk-SNARK in Sapling, and therefore it
|
||
|
relies on relatively strong cryptographic assumptions and a trusted setup. It
|
||
|
would be preferable to force the sender to transfer ``esk`` within the Note
|
||
|
plaintext so that, during note decryption, the recipient can check that ``epk =
|
||
|
[esk] g_d`` (for the expected ``g_d``) and ignore the payment as invalid
|
||
|
otherwise. This forms a line of defense in the case that soundness of the
|
||
|
zk-SNARK does not hold.
|
||
|
|
||
|
Merely sending ``esk`` to the recipient in the Note plaintext would require us
|
||
|
to enlarge the note plaintext, but also would compromise the proof of IND-CCA2
|
||
|
security for in-band secret distribution. We avoid both of these concerns by
|
||
|
using a key derivation to obtain both ``esk`` and ``rcm``.
|
||
|
|
||
|
Specification
|
||
|
=============
|
||
|
|
||
|
Pseudo random functions (PRFs) are defined in section 4.2.1 of the Zcash
|
||
|
Protocol Specification. [#abstractprfs]_ We will be adapting ``PRF^expand`` for
|
||
|
the purposes of this ZIP. This function is keyed by a 256-bit key ``sk`` and
|
||
|
takes an arbitrary length byte sequence as input, returning a 64-byte sequence
|
||
|
as output.
|
||
|
|
||
|
Changes to Sapling Note plaintexts
|
||
|
----------------------------------
|
||
|
|
||
|
Note plaintext encodings are specified in section 5.5 of the Zcash Protocol
|
||
|
Specification. [#notept]_ Currently, the encoding of a Sapling note plaintext
|
||
|
requires that the first byte take the form ``0x01``, indicating the version of
|
||
|
the note plaintext. In addition, a 256-bit ``rcm`` field exists within the note
|
||
|
plaintext and encoding.
|
||
|
|
||
|
Following the activation of this ZIP, the first byte of the encoding MUST take
|
||
|
the form ``0x02`` (representing the new note plaintext version) and the field
|
||
|
``rcm`` of the encoding will be renamed to ``rseed``. This field ``rseed`` of
|
||
|
the Sapling note plaintext will no longer take the type of
|
||
|
`NoteCommit^Sapling.Trapdoor` but will instead be a 32-byte sequence. The
|
||
|
requirement that ``rseed`` (previously, ``rcm``) be a scalar of the Jubjub
|
||
|
elliptic curve, when interpreted as a little endian integer, is removed from the
|
||
|
decryption of note plaintexts as described in sections 4.17.2 and 4.17.3 of the
|
||
|
Zcash Protocol Specification. [#saplingdecryptivk]_ [#saplingdecryptovk]_
|
||
|
|
||
|
Changes to the process of sending Sapling notes
|
||
|
-----------------------------------------------
|
||
|
|
||
|
The process of sending notes in Sapling is described in section 4.6.2 of the
|
||
|
Zcash Protocol Specification. [#saplingsend]_ During this process, the sender
|
||
|
samples ``rcm^new`` uniformly at random. In addition, the process of encrypting
|
||
|
a note is described in section 4.17.1 of the Zcash Protocol Specification.
|
||
|
[#saplingencrypt]_ During this process, the sender also samples the ephemeral
|
||
|
private key ``esk`` uniformly at random.
|
||
|
|
||
|
After the activation of this ZIP, the sender will sample a uniformly random
|
||
|
32-byte sequence ``rseed``. The note plaintext will take ``rseed`` in place of
|
||
|
``rcm^new``.
|
||
|
|
||
|
``rcm^new`` is then computed by the sender as the output of
|
||
|
``ToScalar(PRF^expand_rseed([4]))``.
|
||
|
|
||
|
``esk`` is also computed by the sender as the output of
|
||
|
``ToScalar(PRF^expand_rseed([5]))``.
|
||
|
|
||
|
Changes to the process of receiving Sapling notes
|
||
|
-------------------------------------------------
|
||
|
|
||
|
The process of receiving notes in Sapling is described in sections 4.17.2 and
|
||
|
4.17.3 of the Zcash Protocol Specification. [#saplingdecryptivk]_
|
||
|
[#saplingdecryptovk]_
|
||
|
|
||
|
After the activation of this ZIP, the note plaintext contains a field ``rseed``
|
||
|
that is a 32-byte sequence rather than a scalar value ``rcm``. The recipient,
|
||
|
during decryption and in any later contexts, will interpret the value ``rcm`` as
|
||
|
the output of ``ToScalar(PRF^expand_rseed([4]))``. Further, the recipient MUST
|
||
|
compute ``esk`` as ``ToScalar(PRF^expand_rseed([5]))`` and check that ``epk =
|
||
|
[esk] g_d`` and fail decryption if this check is not satisfied.
|
||
|
|
||
|
Rationale
|
||
|
=========
|
||
|
|
||
|
The attack that this prevents is an interactive attack that requires an
|
||
|
adversary to be able to break critical soundness properties of the zk-SNARKs
|
||
|
underlying Sapling. It is potentially valid to assume that this cannot occur,
|
||
|
due to other damaging effects on the system such as undetectable counterfeiting.
|
||
|
However, we have attempted to avoid any instance in the protocol where privacy
|
||
|
(even against interactive attacks) depended on strong cryptographic assumptions.
|
||
|
Acting differently here would be confusing for users that have previously been
|
||
|
told that "privacy does not depend on zk-SNARK soundness" or similar claims.
|
||
|
|
||
|
It is possible for us to infringe on the length of the ``memo`` field and ask
|
||
|
the sender to provide ``esk`` within the existing note plaintext without
|
||
|
modifying the transaction format, but this would harm users that have come to
|
||
|
expect a 512-byte memo field to be available to them. Changes to the memo field
|
||
|
length should be considered in a broader context than changes made for
|
||
|
cryptographic purposes.
|
||
|
|
||
|
It is possible to transmit a signature of knowledge of a correct ``esk`` rather
|
||
|
than ``esk`` itself, but this appears to be an unnecessary complication and is
|
||
|
likely slower than just supplying ``esk``.
|
||
|
|
||
|
Security and Privacy Considerations
|
||
|
===================================
|
||
|
|
||
|
The changes made in this proposal prevent an interactive attack that could link
|
||
|
together diversified addresses by only breaking the knowledge soundness
|
||
|
assumption of the zk-SNARK. It is already assumed that the adversary cannot
|
||
|
defeat the EC-DDH assumption of the Jubjub elliptic curve, for it could perform
|
||
|
a linkability attack trivially in that case.
|
||
|
|
||
|
In the naive case where the protocol is modified so that ``esk`` is supplied
|
||
|
directly to the recipient (rather than derived through ``rseed``) this would
|
||
|
lead to an instance of key-dependent encryption, which is difficult or perhaps
|
||
|
impossible to prove secure using existing security notions. Our approach of
|
||
|
using a key derivation, which ultimately queries an oracle, allows a proof for
|
||
|
IND-CCA2 security to be written by reprogramming the oracle to return bogus keys
|
||
|
when necessary.
|
||
|
|
||
|
Reference Implementation
|
||
|
========================
|
||
|
|
||
|
TBD
|
||
|
|
||
|
Acknowledgements
|
||
|
================
|
||
|
|
||
|
The discovery that diversified address unlinkability depended on the zk-SNARK
|
||
|
knowledge assumption was made by Sean Bowe and Zooko Wilcox.
|
||
|
|
||
|
References
|
||
|
==========
|
||
|
.. [#protocol] `Zcash Protocol Specification, Version 2020.1.4 [Overwinter+Sapling+Blossom+Heartwood] or later <https://zips.z.cash/protocol/protocol.pdf>`_
|
||
|
.. [#saplingencrypt] `Section 4.17.1: Encryption (Sapling). Zcash Protocol Specification, Version 2020.1.4 [Overwinter+Sapling+Blossom+Heartwood] or later <https://zips.z.cash/protocol/protocol.pdf#saplingencrypt>`_
|
||
|
.. [#abstractprfs] `Section 4.1.2: Pseudo Random Functions. Zcash Protocol Specification, Version 2020.1.4 [Overwinter+Sapling+Blossom+Heartwood] or later <https://zips.z.cash/protocol/protocol.pdf#abstractprfs>`_
|
||
|
.. [#notept] `Section 5.5: Encodings of Note Plaintexts and Memo Fields. Zcash Protocol Specification, Version 2020.1.4 [Overwinter+Sapling+Blossom+Heartwood] or later <https://zips.z.cash/protocol/protocol.pdf#notept>`_
|
||
|
.. [#saplingdecryptivk] `Section 4.17.2: Decryption using an Incoming Viewing Key (Sapling). Zcash Protocol Specification, Version 2020.1.4 [Overwinter+Sapling+Blossom+Heartwood] or later <https://zips.z.cash/protocol/protocol.pdf#saplingdecryptivk>`_
|
||
|
.. [#saplingdecryptovk] `Section 4.17.3: Decryption using a Full Viewing Key (Sapling). Zcash Protocol Specification, Version 2020.1.4 [Overwinter+Sapling+Blossom+Heartwood] or later <https://zips.z.cash/protocol/protocol.pdf#saplingdecryptovk>`_
|
||
|
.. [#saplingsend] `Section 4.6.2: Sending Notes (Sapling). Zcash Protocol Specification, Version 2020.1.4 [Overwinter+Sapling+Blossom+Heartwood] or later <https://zips.z.cash/protocol/protocol.pdf#saplingsend>`_
|