From e38d52c46ffe99cac249b7167d824d196a053d9d Mon Sep 17 00:00:00 2001 From: Henry de Valence Date: Tue, 2 Jun 2020 14:54:54 -0700 Subject: [PATCH] [ZIP 215] Fix Ed25519 validation rules to allow batch verification (#355) * First draft of Ed25519 validation rules. * Add ZIP number. * Clarify language. * Remove Original-Authors when Owners has same value Co-authored-by: Daira Hopwood * Status: Active -> Proposed Co-authored-by: Daira Hopwood * Tidy words Co-authored-by: Daira Hopwood * Clarify libsodium divergence Co-authored-by: Daira Hopwood * Link to rfc8032 * Include references section * Redo * Math syntax Co-authored-by: Daira Hopwood * Update math syntax to match spec for byte-arrays Co-authored-by: Daira Hopwood * Define only the RFC words that are used * Link to spec * Fleshout title * Deployment section * Update zip-0215.rst * Add linebreak Co-authored-by: Deirdre Connolly Co-authored-by: Daira Hopwood --- zip-0215.rst | 102 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 102 insertions(+) create mode 100644 zip-0215.rst diff --git a/zip-0215.rst b/zip-0215.rst new file mode 100644 index 00000000..5e05ebef --- /dev/null +++ b/zip-0215.rst @@ -0,0 +1,102 @@ +:: + + ZIP: 215 + Title: Explicitly define Ed25519 validation rules + Owners: Henry de Valence + Status: Proposed + Category: Consensus + Created: 2020-04-27 + License: BSD-2-Clause + + +Terminology +=========== + +The key word "MUST" in this document is to be interpreted as +described in `RFC2119`_. + +Abstract +======== + +Zcash uses Ed25519 signatures as part of Sprout transactions. However, Ed25519 +does not clearly define criteria for signature validity, and implementations conformant +to `RFC8032`_ need not agree on whether signatures are valid. This is +unacceptable for a consensus-critical application like Zcash. Currently, Zcash +inherits criteria for signature verification from an obsolete version of +`libsodium`. Instead, this ZIP settles the situation by explicitly defining the +Ed25519 verification criteria and changing them to be compatible with batch +verification. + +Motivation +========== + +The lack of clear verification criteria for Ed25519 signatures poses a +maintenance burden. The initial implementation of Zcash consensus in `zcashd` +inherited validation criteria from a then-current version of `libsodium` (1.0.15). +Due to `a bug in libsodium `_, +this was different from the intended criteria documented in the Zcash protocol +specification [#protocol]_ (before the specification was changed to match +`libsodium` 1.0.15 in specification version 2020.1.2). Also, `libsodium` never +guaranteed stable validation criteria, and changed behavior in a later point +release. This forced `zcashd` to use an older version of the library before +eventually patching a newer version to have consistent validation criteria. +To be compatible, Zebra had to implement a special library, `ed25519-zebra` to +provide Zcash-flavored Ed25519, attempting to match `libsodium` 1.0.15 exactly. And +the initial attempt to implement `ed25519-zebra` was also incompatible, because +it precisely matched the wrong compile-time configuration of `libsodium`. + +In addition, the validation criteria used by Zcash preclude the use of batch +verification of Ed25519 signatures. While signature verification is not the +primary bottleneck for Zcash, it would be nice to be able to batch-verify +signatures, as is the case for RedJubJub. + +Specification +============= + +After activation of this ZIP, the `JoinSplitSig` validation rules in §5.4.5 of the +protocol specification [#protocol]_ are changed to the following: + +- :math:`\underline{A}` and :math:`\underline{R}` MUST be encodings of a point on the Edwards form of Curve25519; +- :math:`underline{S}` MUST represent an integer less than :math:`\ell`; +- The group equation `[8][s]B = [8]R + [8][k]A` MUST be satisfied, where `k` is defined as in RFC 8032 §5.1.7. + +The language about `ExcludedPointEncodings` in §5.4.5 of the Zcash +specification is deleted. + +It is *not* required that `A` and `R` are canonical encodings; in other words, +the integer encoding the `y`-coordinate of the points may be unreduced modulo +`2^255-19`. + +Rationale +========= + +This change simplifies the Ed25519 validation logic and reduces future +maintenance burden. Because multiplication by the cofactor admits more +solutions to the verification equation, not fewer, it is compatible with all +existing Ed25519 signatures on the chain. + +It also allows the use of batch verification, which requires multiplication +by the cofactor in the verification equation. + +Security and Privacy Considerations +=================================== + +This change has no effect on honestly-generated signatures. Unlike the current +validation rules, it makes it possible for a user to generate weak signing keys +or to generate signing keys with nonzero torsion component and submit them to +the blockchain. However, doing so provides them with no advantage, only +compromise to their own security. Moreover, these cases are not a failure mode +of any deployed implementation. + +Deployment +========= + +This is intended to be deployed with the Canopy Network Upgrade, which is +scheduled to activate on mainnet at block height 1046400. + +References +========== + +.. [#RFC2119] `Key words for use in RFCs to Indicate Requirement Levels `_ +.. [#RFC8032] `Edwards-Curve Digital Signature Algorithm (EdDSA) `_ +.. [#protocol] `Zcash Protocol Specification, Version {...} or later [Overwinter+Sapling+Blossom] `_