forked from zcash/zips
-
Notifications
You must be signed in to change notification settings - Fork 0
/
zip-0215.html
134 lines (134 loc) · 10.6 KB
/
zip-0215.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
<!DOCTYPE html>
<html>
<head>
<title>ZIP 215: Explicitly Defining and Modifying Ed25519 Validation Rules</title>
<meta charset="utf-8" />
<script src="https://cdn.jsdelivr.net/npm/mathjax@3/es5/tex-mml-chtml.js?config=TeX-AMS-MML_HTMLorMML"></script>
<meta name="viewport" content="width=device-width, initial-scale=1"><link rel="stylesheet" href="css/style.css"></head>
<body>
<section>
<pre>ZIP: 215
Title: Explicitly Defining and Modifying Ed25519 Validation Rules
Owners: Henry de Valence <hdevalence@zfnd.org>
Status: Implemented (zcashd)
Category: Consensus
Created: 2020-04-27
License: BSD-2-Clause</pre>
<section id="terminology"><h2><span class="section-heading">Terminology</span><span class="section-anchor"> <a rel="bookmark" href="#terminology"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The key words "MUST" and "MUST NOT" in this document is to be interpreted as described in RFC 2119. <a id="id1" class="footnote_reference" href="#rfc2119">1</a></p>
</section>
<section id="abstract"><h2><span class="section-heading">Abstract</span><span class="section-anchor"> <a rel="bookmark" href="#abstract"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>Zcash uses Ed25519 signatures as part of Sprout transactions. However, Ed25519 does not clearly define criteria for signature validity, and implementations conformant to RFC 8032 <a id="id2" class="footnote_reference" href="#rfc8032">2</a> need not agree on whether signatures are valid. This is unacceptable for a consensus-critical application like Zcash. Currently, Zcash inherits criteria for signature validity from an obsolete version of <cite>libsodium</cite>. Instead, this ZIP settles the situation by explicitly defining the Ed25519 validity criteria and changing them to be compatible with batch validation.</p>
</section>
<section id="motivation"><h2><span class="section-heading">Motivation</span><span class="section-anchor"> <a rel="bookmark" href="#motivation"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>The lack of clear validity criteria for Ed25519 signatures poses a maintenance burden. The initial implementation of Zcash consensus in <cite>zcashd</cite> inherited validity criteria from a then-current version of <cite>libsodium</cite> (1.0.15). Due to <a href="https://github.com/zcash/zcash/issues/2872#issuecomment-576911471">a bug in libsodium</a>, this was different from the intended criteria documented in the Zcash protocol specification <a id="id3" class="footnote_reference" href="#protocol-2020-1-1">3</a> (before the specification was changed to match <cite>libsodium</cite> 1.0.15 in specification version 2020.1.2). Also, <cite>libsodium</cite> never guaranteed stable validity criteria, and changed behavior in a later point release. This forced <cite>zcashd</cite> to use an older version of the library before eventually patching a newer version to have consistent validity criteria. To be compatible, Zebra had to implement a special library, <cite>ed25519-zebra</cite> to provide Zcash-flavored Ed25519, attempting to match <cite>libsodium</cite> 1.0.15 exactly. And the initial attempt to implement <cite>ed25519-zebra</cite> was also incompatible, because it precisely matched the wrong compile-time configuration of <cite>libsodium</cite>.</p>
<p>In addition, the validity criteria used by Zcash preclude the use of batch validation of Ed25519 signatures. While signature validation is not the primary bottleneck for Zcash, it would be nice to be able to batch-validate signatures, as is the case for RedJubjub.</p>
</section>
<section id="specification"><h2><span class="section-heading">Specification</span><span class="section-anchor"> <a rel="bookmark" href="#specification"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>After activation of this ZIP, the
<span class="math">\(\mathsf{JoinSplitSig}\)</span>
validation rules in <a id="id4" class="footnote_reference" href="#protocol-concreteed25519">5</a> are changed to the following:</p>
<ul>
<li>
<span class="math">\(\underline{A}\)</span>
and
<span class="math">\(\underline{R}\)</span>
MUST be encodings of points
<span class="math">\(A\)</span>
and
<span class="math">\(R\)</span>
respectively on the complete twisted Edwards curve Ed25519;</li>
<li>
<span class="math">\(\underline{S}\)</span>
MUST represent an integer
<span class="math">\(S\)</span>
less than
<span class="math">\(\ell\)</span>
;</li>
<li>The group equation
<span class="math">\([8][S]B = [8]R + [8][k]A\)</span>
MUST be satisfied, where
<span class="math">\(k\)</span>
and
<span class="math">\(B\)</span>
are defined as in RFC 8032 sections §5.1.7 and §5.1 respectively. <a id="id5" class="footnote_reference" href="#rfc8032">2</a></li>
</ul>
<p>The language about
<span class="math">\(\mathsf{ExcludedPointEncodings}\)</span>
in §5.4.5 of the Zcash specification <a id="id6" class="footnote_reference" href="#protocol-concreteed25519">5</a> no longer applies.</p>
<p>It is <em>not</em> required that
<span class="math">\(\underline{A}\)</span>
and
<span class="math">\(\underline{R}\)</span>
are canonical encodings; in other words, the integer encoding the
<span class="math">\(y\)</span>
-coordinate of the points may be unreduced modulo
<span class="math">\(2^{255}-19\)</span>
.</p>
<p>Note: the alternate validation equation
<span class="math">\([S]B = R + [k]A\)</span>
, allowed by RFC 8032, MUST NOT be used.</p>
</section>
<section id="rationale"><h2><span class="section-heading">Rationale</span><span class="section-anchor"> <a rel="bookmark" href="#rationale"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This change simplifies the Ed25519 validation logic and reduces future maintenance burden. Because multiplication by the cofactor admits more solutions to the validation equation, not fewer, it is compatible with all existing Ed25519 signatures on the chain.</p>
<p>It also allows the use of batch validation, which requires multiplication by the cofactor in the validation equation.</p>
</section>
<section id="security-and-privacy-considerations"><h2><span class="section-heading">Security and Privacy Considerations</span><span class="section-anchor"> <a rel="bookmark" href="#security-and-privacy-considerations"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>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.</p>
</section>
<section id="deployment"><h2><span class="section-heading">Deployment</span><span class="section-anchor"> <a rel="bookmark" href="#deployment"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<p>This is intended to be deployed with the Canopy Network Upgrade <a id="id7" class="footnote_reference" href="#zip-0251">6</a>, which is scheduled to activate on Mainnet <a id="id8" class="footnote_reference" href="#protocol-networks">4</a> at block height 1046400.</p>
</section>
<section id="references"><h2><span class="section-heading">References</span><span class="section-anchor"> <a rel="bookmark" href="#references"><img width="24" height="24" src="assets/images/section-anchor.png" alt=""></a></span></h2>
<table id="rfc2119" class="footnote">
<tbody>
<tr>
<th>1</th>
<td><a href="https://www.rfc-editor.org/rfc/rfc2119.html">RFC 2119: Key words for use in RFCs to Indicate Requirement Levels</a></td>
</tr>
</tbody>
</table>
<table id="rfc8032" class="footnote">
<tbody>
<tr>
<th>2</th>
<td><a href="https://www.rfc-editor.org/rfc/rfc8032.html">RFC 8032: Edwards-Curve Digital Signature Algorithm (EdDSA)</a></td>
</tr>
</tbody>
</table>
<table id="protocol-2020-1-1" class="footnote">
<tbody>
<tr>
<th>3</th>
<td><a href="https://github.com/zcash/zips/blob/v2020.1.1/protocol/protocol.pdf">Zcash Protocol Specification, Version 2020.1.1</a></td>
</tr>
</tbody>
</table>
<table id="protocol-networks" class="footnote">
<tbody>
<tr>
<th>4</th>
<td><a href="protocol/protocol.pdf#networks">Zcash Protocol Specification, Version 2020.1.15. Section 3.11: Mainnet and Testnet</a></td>
</tr>
</tbody>
</table>
<table id="protocol-concreteed25519" class="footnote">
<tbody>
<tr>
<th>5</th>
<td><a href="protocol/protocol.pdf#concreteed25519">Zcash Protocol Specification, Version 2020.1.15. Section 5.4.5: Ed25519</a></td>
</tr>
</tbody>
</table>
<table id="zip-0251" class="footnote">
<tbody>
<tr>
<th>6</th>
<td><a href="zip-0251">ZIP 251: Deployment of the Canopy Network Upgrade</a></td>
</tr>
</tbody>
</table>
</section>
</section>
</body>
</html>