1 // Copyright (c) 2020-2022 The Decred developers
2 // Use of this source code is governed by an ISC
3 // license that can be found in the LICENSE file.
4 5 // Package schnorr provides custom Schnorr signing and verification via
6 // secp256k1.
7 //
8 // This package provides data structures and functions necessary to produce and
9 // verify deterministic canonical Schnorr signatures using a custom scheme named
10 // EC-Schnorr-DCRv0 that is described herein. The signatures and implementation
11 // are optimized specifically for the secp256k1 curve. See
12 // https://www.secg.org/sec2-v2.pdf for details on the secp256k1 standard.
13 //
14 // It also provides functions to parse and serialize the Schnorr signatures
15 // according to the specification described herein.
16 //
17 // A comprehensive suite of tests is provided to ensure proper functionality.
18 //
19 // # Overview
20 //
21 // A Schnorr signature is a digital signature scheme that is known for its
22 // simplicity, provable security and efficient generation of short signatures.
23 //
24 // It provides many advantages over ECDSA signatures that make them ideal for
25 // use with the only real downside being that they are not well standardized at
26 // the time of this writing.
27 //
28 // Some of the advantages over ECDSA include:
29 //
30 // - They are linear which makes them easier to aggregate and use in
31 // protocols that build on them such as multi-party signatures, threshold
32 // signatures, adaptor signatures, and blind signatures
33 // - They are provably secure with weaker assumptions than the best known
34 // security proofs for ECDSA
35 // - Specifically Schnorr signatures are provably secure under SUF-CMA (Strong
36 // Existential Unforgeability under Chosen Message Attack) in the ROM
37 // (Random Oracle Model) which guarantees that as long as the hash
38 // function behaves ideally, the only way to break Schnorr signatures is
39 // by solving the ECDLP (Elliptic Curve Discrete Logarithm Problem).
40 // - Their relatively straightforward and efficient aggregation properties
41 // make them excellent for scalability and allow them to provide some nice
42 // secrecy characteristics
43 // - They support faster batch verification unlike the standardized version of
44 // ECDSA signatures
45 //
46 // # Custom Schnorr-based Signature Scheme
47 //
48 // As mentioned in the overview, the primary downside of Schnorr signatures for
49 // elliptic curves is that they are not standardized as well as ECDSA signatures,
50 // which means there are a number of variations that are not compatible with
51 // each other.
52 //
53 // In addition, many of the standardization attempts have had various
54 // disadvantages that make them unsuitable for use in Decred. Some of these
55 // details and some insight into the design decisions made are discussed further
56 // in the README.md file.
57 //
58 // Consequently, this package implements a custom Schnorr-based signature scheme
59 // named EC-Schnorr-DCRv0 suitable for use in Decred.
60 //
61 // The following provides a high-level overview of the key design features of
62 // the scheme:
63 //
64 // - Uses signatures of the form (R, s)
65 // - Produces 64-byte signatures by only encoding the x coordinate of R
66 // - Enforces even y coordinates for R to support efficient verification by
67 // disambiguating the two possible y coordinates
68 // - Canonically encodes by both components of the signature with 32-bytes
69 // each
70 // - Uses BLAKE-256 with 14 rounds for the hash function to calculate
71 // challenge e
72 // - Uses RFC6979 to obviate the need for an entropy source at signing time
73 // - Produces deterministic signatures for a given message and secret key pair
74 //
75 // # EC-Schnorr-DCRv0 Specification
76 //
77 // See the README.md file for the specific details of the signing and
78 // verification algorithm as well as the signature serialization format.
79 //
80 // # Future Design Considerations
81 //
82 // It is worth noting that there are some additional optimizations and
83 // modifications that have been identified since the introduction of
84 // EC-Schnorr-DCRv0 that can be made to further harden security for multi-party
85 // and threshold signature use cases as well provide the opportunity for faster
86 // signature verification with a sufficiently optimized implementation.
87 //
88 // However, the v0 scheme is used in the existing consensus rules and any
89 // changes to the signature scheme would invalidate existing uses. Therefore
90 // changes in this regard will need to come in the form of a v1 signature scheme
91 // and be accompanied by the necessary consensus updates.
92 //
93 // # Schnorr use in Decred
94 //
95 // At the time of this writing, Schnorr signatures are not yet in widespread use
96 // on the Decred network, largely due to the current lack of support in wallets
97 // and infrastructure for secure multi-party and threshold signatures.
98 //
99 // However, the consensus rules and scripting engine supports the necessary
100 // primitives and given many of the beneficial properties of Schnorr signatures,
101 // a good goal is to work towards providing the additional infrastructure to
102 // increase their usage.
103 package schnorr
104