Use uECC instead of Crypto++ for ECDH

[arkpar]

No description provided.

[arkpar]

One of the steps to get rid of libcrypto++
library source: https://github.com/kmackay/micro-ecc

[subtly]

Nice! Will test on the various OSs (hopefully jenkins can do this too!)

[subtly]

I don't think we should remove this check and/or may need to add a flag (default to verify) for toPublic.

[arkpar]

The check is done in toPublic anyway, it will return zero in case of invalid key. As far as I understand crypto++ validate() checks for curve validity, which is not needed for libsecp256k1 anyway and also checks that the point is valid on the curve, which secp256k1_ec_pubkey_create also does.
The previous behavior of this function for invalid secret was to set m_secret to invalid key, but leave m_public and m_address to the previous value. With this change m_public and m_address will be set to zero, which is better since these don't throw anyway.

[chfast]

Maybe a newbe question, but why not ECDH from secp256k1?

[arkpar]

Last time I checked It was not supported. At least the version in webthree-helpers does not have any API for ECDH

[chfast]

It is implemented as a module in upstream repo:
https://github.com/bitcoin/secp256k1/blob/master/src/modules/ecdh/main_impl.h

Can you verify that this short implementation is good for us?

[arkpar]

This header is not enough, we need to update the library. I will try and do that

[chfast]

@subtly had opinions about upgrading secp256k1.

[Gustav-Simonsson]

Go integration of libsecp256k1 ECDH: ethereum/go-ethereum#1862
It modifies the source to return the point x value before the SHA256 hashing, since RLPx uses it's own hashing of the raw secret.

[arkpar]

dropped in favor of libsecp256k1