[curves] Climbing the elliptic learning curve

[Ray Dillinger]

On 02/02/2017 01:19 PM, Trevor Perrin wrote:
> On Tue, Jan 31, 2017 at 2:32 AM, Antonio Sanso <asanso at adobe.com> wrote:
>
>> in which situation not checking for the “right” public key can be a problem?
>> Trevor mentioned already one situation, but I fail to see without the knowledge
>> of the associated private key, where this could be an harm…. 
> 
> A key exchange protocol might want to guarantee that if the protocol
> completes successfully, both parties have the same secret key *and*
> agree on things like the identities of the two parties.
> 
> So if an attacker can change a transmitted public key into a
> different-but-equivalent public key, a protocol might complete
> successfully despite the parties having a different view of the public
> keys.

There was a bug related to this with the Bitcoin block chain which was
exposed by an SSL upgrade.  The SSL software began failing signature
checks that were signed by anything other than the 'canonical version'
of the key.  But the block chain already had (and still has) some
transactions in it that were signed by various different equivalent
keys.  When these transactions started failing the signature checks, it
meant that checking the integrity of the block chain failed for anyone
who had done the most recent SSL upgrade.

It was dead-easy to fix it so no new transactions with variant forms of
the key would be made, but it was no longer sufficient to call SSL to
check signatures on the block chain, and the block chain cannot be
rewritten to update the keys.

It got fixed over a year ago, and the current version of Bitcoin has
code specifically to check transactions signed with variant forms of
keys no longer recognized by SSL.

This was mostly a 'mismatch of purpose' bug; the SSL maintainers
consider it a networking library where the form of keys used in earlier
sessions or certificates is completely irrelevant to current sessions;
Bitcoin was using SSL signatures to establish an irrevocable recorded
history and needed those old signatures to continue to be provably valid.

The short version of that story is that if you're using any library for
something that is not what the maintainers think it's for, sooner or
later there's going to be an 'upgrade' that breaks your application.


				Bear



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://moderncrypto.org/mail-archive/curves/attachments/20170202/2f040bf7/attachment.sig>