From: Peter Todd <pete@petertodd•org>
To: Gregory Maxwell <gmaxwell@gmail•com>
Cc: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] OpenSSL 1.0.0p / 1.0.1k incompatible, causes blockchain rejection.
Date: Sat, 10 Jan 2015 00:40:38 -0500 [thread overview]
Message-ID: <20150110054038.GA2048@savin.petertodd.org> (raw)
In-Reply-To: <CAAS2fgR2a+3wb+He611pxy_Ypur0gq+o7SRjUHa4-R+xHLLnyA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2474 bytes --]
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".
>
> 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¹ 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_notes_say_we_have_reason_to/
--
'peter'[:-1]@petertodd.org
000000000000003b82d8644b56c846e7497118b04a6ec68d3e0a23d33323b82e
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
next prev parent reply other threads:[~2015-01-10 5:40 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-10 4:26 Gregory Maxwell
2015-01-10 5:40 ` Peter Todd [this message]
2015-01-10 8:35 ` Wladimir
2015-01-10 12:18 ` Ivan Jelincic
2015-01-12 9:40 ` Wladimir
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150110054038.GA2048@savin.petertodd.org \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=gmaxwell@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox