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
135
136
137
138
139
140
141
142
143
144
145
146
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1Y9on6-0001FJ-Fs
for bitcoin-development@lists.sourceforge.net;
Sat, 10 Jan 2015 05:40:52 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.148.114 as permitted sender)
client-ip=62.13.148.114; envelope-from=pete@petertodd.org;
helo=outmail148114.authsmtp.net;
Received: from outmail148114.authsmtp.net ([62.13.148.114])
by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1Y9on3-0001un-Sc for bitcoin-development@lists.sourceforge.net;
Sat, 10 Jan 2015 05:40:52 +0000
Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237])
by punt14.authsmtp.com (8.14.2/8.14.2) with ESMTP id t0A5ehcW079118;
Sat, 10 Jan 2015 05:40:43 GMT
Received: from savin.petertodd.org (75-119-251-161.dsl.teksavvy.com
[75.119.251.161]) (authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t0A5edkp074096
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Sat, 10 Jan 2015 05:40:41 GMT
Date: Sat, 10 Jan 2015 00:40:38 -0500
From: Peter Todd <pete@petertodd.org>
To: Gregory Maxwell <gmaxwell@gmail.com>
Message-ID: <20150110054038.GA2048@savin.petertodd.org>
References: <CAAS2fgR2a+3wb+He611pxy_Ypur0gq+o7SRjUHa4-R+xHLLnyA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="7AUc2qLy4jB3hD7Z"
Content-Disposition: inline
In-Reply-To: <CAAS2fgR2a+3wb+He611pxy_Ypur0gq+o7SRjUHa4-R+xHLLnyA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 371dd4e1-988b-11e4-9f74-002590a135d3
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aAdMdwIUElQaAgsB AmMbW1FeVF17XWE7 bA9PbARUfEhLXhtr
VklWR1pVCwQmRRxw A0tKCVlycAFGcXg+ ZERgXXEVX0N7IRJ5
F09JHGUON3phaTUb TUkOcAdJcANIexZF O1F8UScOLwdSbGoL
NQ4vNDcwO3BTJTpY RgYVKF8UXXNDOSYx QSs5OX12WxVDHz17
aFR/bAZaRUVZM0M5 Nl45UE4ZORsfTm8W FEhQGyJCb1MFQCEo
BgNTXEhWCjBfTCxA AxouZHdA
X-Authentic-SMTP: 61633532353630.1024:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 75.119.251.161/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
X-Spam-Score: -1.5 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
-0.0 SPF_PASS SPF: sender matches SPF record
X-Headers-End: 1Y9on3-0001un-Sc
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] OpenSSL 1.0.0p / 1.0.1k incompatible,
causes blockchain rejection.
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Sat, 10 Jan 2015 05:40:52 -0000
--7AUc2qLy4jB3hD7Z
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sat, Jan 10, 2015 at 04:26:23AM +0000, Gregory Maxwell wrote:
> The incompatibility is due to the OpenSSL update changing the
> behavior of ECDSA validation to reject any signature which is
> not encoded in a very rigid manner. This was a result of
> OpenSSL's change for CVE-2014-8275 "Certificate fingerprints
> can be modified".
>=20
> While for most applications it is generally acceptable to eagerly
> reject some signatures, Bitcoin is a consensus system where all
> participants must generally agree on the exact validity or
> invalidity of the input data. In a sense, consistency is more
> important than "correctness".
As an aside, it's interesting to note that this issue is not entirely
unique to miners.
For example in micropayment channel protocols the receiver must validate
signatures from the sender to ensure that they will be able to broadcast
transactions containing those signatures in the near-future. If they
accept a signature as valid that the majority of hashing power rejects
as invalid the sender can simply wait until the micropayment channel
timeout expires to recover 100% of their funds, ripping off the
receiver. There's many other advanced Bitcoin protocols with similar
vulnerabilities; I'd be interested to hear if anyone can come up with a
similar vulnerability in a non-Bitcoin protocol, and wouldn't be that
surprised if they did.
While I have often cautioned people before to avoid using libsecp256k1
for verification on the grounds that consensus trumps correctness, the
above incompatibility does strongly suggest that OpenSSL may not itself
have very good consensus-critical design. Along with Maxwell and
Wuille's recent findings=B9 CVE-2014-3570 - strong evidence of the
excellent testing the library has undergone - I personally am now of the
opinion that migrating Bitcoin Core to libsecp256k1 in the near future
is a good idea on the grounds that it provides us with a well-written,
and well-understood library designed with consensus in mind that'll
probably give us fewer consensus problems than our existing OpenSSL
dependency. It'll also help advanced protocol implementations by giving
them a clear dependency to use when they need consensus-critical
signature evaluation.
1) https://www.reddit.com/r/Bitcoin/comments/2rrxq7/on_why_010s_release_not=
es_say_we_have_reason_to/
--=20
'peter'[:-1]@petertodd.org
000000000000003b82d8644b56c846e7497118b04a6ec68d3e0a23d33323b82e
--7AUc2qLy4jB3hD7Z
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iQGrBAEBCACVBQJUsLtSXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwNDk4ZGI3OTRjOGRkM2U2OGIxZDVmOTRkNTFkYjQ5NzM5ZTNk
ZDc4OTFlNzMxNWIxZGIvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkft+eggAqMu14OQabJRJDwBBeD+2zN5h
15Z56MQN8WuzlgCoIL51jrnaAMVpmBfHZLxzksn5VUe30H+QiopnD27yUlC+sIqt
yaHMdw0lrXAMeqA+LRkH5wxgozRY/TSqiDuO4x/gKe5vT36Mzjr0cSN57nvsBCGC
D+r1O6IjVMEGmFD0mEV1f8b63WYP/hcGOOifNp9SgYXnhn2a2PW0xTmZvpxtZZr6
vYwHDq854jNh/kWrpoZFVllwRujMbxigydy79YzjynlBS8+CwuQq8caHJ3ScnIf2
uz114AWklGnwkrdJM6ENVNkrdFdOgjw1qiacsuZThGffeAwERgK2kE3QgmGMkA==
=FG6G
-----END PGP SIGNATURE-----
--7AUc2qLy4jB3hD7Z--
|
